We'd want to use SHA256 but that's an OK thing to do AFAIK. I wouldn't agree to it in a security patch because it breaks backwards compatibility in a much larger way than the patch we did does.
In fact we already do this with the bcrypt hasher in Django 1.6+ to solve a password truncation issue (Bcrypt truncates the input password before hashing it). https://code.djangoproject.com/ticket/20138 http://security.stackexchange.com/questions/6623/pre-hash-password-before-applying-bcrypt-to-avoid-restricting-password-length On Sep 15, 2013, at 5:45 AM, Ram Rachum <ram.rac...@gmail.com> wrote: > Thanks Curtis! > > I thought about my idea and realized it makes a brute-force attack easier, > and we'd have to make the hashing stronger to compensate... Making the > computation time longer for the real users logging in... So yeah, it won't > help. > > But then I had another idea. So PBKDF2 takes a longer time to calculate for > longer passwords. Maybe the solution is to fix that? That would be more > elegant than limiting passwords to 4096 (because then dos attackers can still > attack using 4096-long passwords, and while not as slow as megabytes-long > password, it's still slow.) > > What if instead of calculating the PBKDF2 hash of the password, we'll > calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking > passwords wouldn't depend on their length, and we wouldn't even have to place > a limit of 4096 characters on passwords-- An attacker could try a 1MB-long > password but it would slow us down the same amount as trying "123456" would. > > What do you think? > > On Sunday, September 15, 2013 12:25:32 PM UTC+3, Curtis Maloney wrote: > Actually, you'd just speed up their attack, since most failed attempts would > be quicker than others. > > If you look in the crypto utils, you'll see a "constant time compare" ... > this is a common thing in crypto circles to avoid leaking "how close" the > guess was by how quickly the mismatch was found. > > This is a class of "side channel attach"... worth reading up on if you want > to get further into crypto: http://en.wikipedia.org/wiki/Side_channel_attack > > -- > Curtis > > > > On 15 September 2013 19:00, Ram Rachum <ram.r...@gmail.com> wrote: > Hi guys, > > I just saw the new release announcement and I had an idea. > > What if, in addition to sorting the hard to compute hash for every password, > we will also store the sha 1 hash of the first 5 characters ofthe password's > sha1 hash? Wouldn't this allow us to quickly rule out 99% of passwords, > thereby defending against dos attacks, while atthe same time not letting an > attacker who obtained the hashes to get the passwords? > > I'm not a security expert, just brainstorming. > > Thanks, > Ram. > > -- > 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 django-develop...@googlegroups.com. > To post to this group, send email to django-d...@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > 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 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. > For more options, visit https://groups.google.com/groups/opt_out. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
