It is once per user, but it's once for *EVERY* user when that scenario occurs. That could easily bring a site down if sessions were invalidated or you have short session times. It's far too likely someone will have serious, hard to debug problems as a result of this magical behaviour.
I also strongly agree with Carl's comment on the PR: Automatic changes in behaviour based only on the presence or absence of a third-party package (or C bindings) are questionable in general. We can (and by the sounds of it should) recommend this hasher strongly, but I don't think we need to make it the default. Unlike SHA256, PBKDF2 isn't a BAD choice yet, it's just not the best available. There's an argument for updating the default project template for new projects, but that would make setup for new users a lot harder so I don't really like that idea either. On 29 January 2016 at 14:56, Bas Westerbaan <b...@westerbaan.name> wrote: > > > I may not understand the security implications here properly, but as far > as I can tell there isn't a strong enough case that Argon2 is fundamentally > better than PBKDF2 yet? > > > Barring any weakness in Blake2 we do not know about, Argon2 is way better > than PBKDF2 as it is memory-hard. The gap between SHA256 and PBKDF2 *and* > PBKDF2 > and Argon2 (with Django’s settings) might be of comparable order of > magnitude as I outlined in this comment[1]. > > I'd say 1.3 seconds is fundamentally *not* fast enough. If someone > upgrades their site to Django 1.10 without noticing the change and we force > this upgrade the suddenly every user's login to the site costs 1.3 seconds > - that's an enormous amount of server load. > > > That’s not my suggestion. Sorry I did state it clearly enough. This 1.3 > second login will only happen if the server used to be able to use the fast > C-argon2 library, but then can’t use it anymore. This 1.3 second login > will only happen once per user: Django would then switch back to PBKDF2. A > 1.3 second login *once* per user seems acceptable. (Off course it’s not > acceptable if it would happen every time the user logs in.) > > Best, > > Bas > > [1] https://github.com/django/django/pull/5876#discussion_r48936346 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/BCEDC782-875E-474C-8B36-C2D59F430913%40westerbaan.name > <https://groups.google.com/d/msgid/django-developers/BCEDC782-875E-474C-8B36-C2D59F430913%40westerbaan.name?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1F1YVspthGnAnCwJDD22-2z2n90aXWCxVxxa9a-pvAFgg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
