Right -- the performance is only slightly worse during an upgrade than during other actions. I found the conversation I was thinking about. It's in the private security tracker (the patch to upgrade the iterations count was developed there), so I'll copy/paste the relevant bits here. The patch in question is https://github.com/django/django-private/commit/7d0d0dbf26a3c0d16e9c2b930fd6d7b89f215946
Paul McMillan: "I don't believe this is necessary" Donald Stufft: @PaulMcMillan Why? I think it's a good change and I think it's needed. Otherwise in X years people created with a 1.4 era hasher will have severely weaker password hashes. P: "Upgrading hashes like the patch does causes double the login load after any upgrade. The hashing margin is already high, and having "my server's running really slow and everything broke after I upgraded" is not a good deployment experience. It will also cause people to say "hmm, maybe these new hashes are too many rounds, let's switch to something less secure". @dstufft "severely weaker" is an overstatement. Any security change which dramatically changes the load on a server is something we have to weigh extremely carefully. I don't think this is an acceptable tradeoff. The design goal was to have hashes gradually get upgraded as users create new passwords or change existing ones. This allows admins to see the load increasing gradually, and plan server resources accordingly. Walloping them with a wall of increased load immediately after upgrade isn't fair, and discourages users from upgrading." D: "@PaulMcMillan I don't believe I agree with that. Using PBKDF2 is already a fraction of what you get with bcrypt so by that logic we shouldn't allow any use of bcrypt either. Notably passlib supports this upgrading of hash iterations (although they have a range of acceptable values). Severely weaker isn't an understatement. It takes 5 releases past whichever release increases the limit to 12000 to get roughly double the iterations from the 1.4 number of 10k. As far as I know Django is planning on a 6month release schedule so that means 2 and a half years any user who was created with a 1.4, 1.5, 1.6 installation has a password hash half as strong as one created in 2 years. There's no way for that user to *get* a stronger hash besides change their password which most users do not do unless forced to. P: "`<shrug>` ok then. As I've said before, anyone using this in large scale production is probably using weaker hashers anyway. It's really a nasty surprise to have user logins take more than twice as much cpu when you bring the site back from any major upgrade, but I guess most people won't even notice that, since they aren't running at scale. Too bad this isn't the sort of behavior a large deployment is likely to notice during pre-upgrade testing before it bites them in the ass during a real upgrade with users hammering the server trying to get back in after planned downtime." ------------------ At this point, I'm inclined to continue with the 20-25% iterations increase per release methodology we've been using unless someone wants to advocate for one of the other proposals. We only have 2 releases left (1.10 and 1.11) that will support Python 2. After dropping Python 2 and any chance that someone will be using the slower pbkdf2, we can reevaluate. On Tuesday, September 22, 2015 at 2:59:18 PM UTC-4, Alex_Gaynor wrote: > > Sure, but such a problem has nothing to do with password upgrades, it can > already be triggered by registration, or even just logging in without a > password upgrade. > > Alex > > On Tue, Sep 22, 2015 at 2:43 PM, Tim Graham <timog...@gmail.com > <javascript:>> wrote: > >> Sorry, I explained poorly. We do upgrade passwords when the iteration >> count is increased >> https://docs.djangoproject.com/en/1.8/topics/auth/passwords/#password-upgrading >> >> If we increase the iterations to <new iterations>, when a user logs in, >> we have to hash <current iterations> to check the password against the >> current hash plus <new iterations> to store the upgraded password. If >> pbkdf2 is slow, isn't it reasonable that this could cause a CPU spike on a >> high traffic site? >> >> On Tuesday, September 22, 2015 at 1:39:12 PM UTC-4, Xof wrote: >>> >>> >>> On Sep 22, 2015, at 10:27 AM, Tim Graham <timog...@gmail.com> wrote: >>> >>> > We have access to the plain text password when the user logs in. >>> >>> Right, so we could *in theory* upgrade the user's password then if we >>> wished (not clear if we want to). Even so, I don't think that would be a >>> DDoS-attack level problem, since it's no worse than a user resetting their >>> password. >>> >>> -- >>> -- Christophe Pettus >>> x...@thebuild.com >>> >>> -- >> 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-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/bd8df6d7-4355-427e-83b4-024482e2fdf0%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/bd8df6d7-4355-427e-83b4-024482e2fdf0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2e6a27c0-2488-4fcd-b322-84bc28cc592f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
