Hi, there are a few things which worry me about this patch (aside from the note from charettes). You write "and the DoS attack vector is avoided" which is not true, hashing functions are by design CPU-intensive so you are not avoiding DoS, even if hashing now consistently takes less (for short passwords more) time you still can DoS a site. Avoiding the DoS vector in this case would mean something like rate limiting… And curious, why are you not able to run the tests, it's as simple as "cd tests; ./runtests". No offense, but copying those few lines and adding a broken test isn't really helping that much…
I am also not sure if we would want to use this as default hasher at all, the current default isn't that bad and puts a limit onto the hashing like yours does (granted, a bit later timewise, but as I said before changing the hash function is not a longterm solution). Cheers, Florian On Sunday, September 15, 2013 10:27:16 PM UTC+2, Ram Rachum wrote: > > Submitted patch: > > https://code.djangoproject.com/ticket/21105#comment:1 > > On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote: >> >> >> On Sep 15, 2013, at 2:59 PM, Florian Apolloner <[email protected]> >> wrote: >> >> Hi Ram, >> >> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote: >>> >>> Florian, I'm not sure that you read my message carefully enough. I'm *not >>> *proposing to reduce the time that PBKDF2 takes to hash. >>> >> >> By replacing the password with a hash before running it through PBKDF2 >> you are reducing that time for every password longer than the hash… And >> given the way PBKDF2 works you'll reduce it by quite a bit (note that all >> of this only applies to passwords longer than the hash, so it's probably >> pretty academical). Either way, we'd at least need a new hasher class since >> it would be backwards incompatible. Independent of that we'd have to >> evaluate if pre-hashing the password could make PBKDF2 less secure >> (probably not to likely, but who knows). >> >> >> According to Thomas Porin in the context of bcrypt pre-hashing the >> password is fine (and we already do this in Django 1.6). I see no reason >> the same wouldn't hold true for PBKDF2. >> >> ----------------- >> Donald Stufft >> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 >> DCFA >> >> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
