Re: Idea about authentication
We already committed a fix for pbkdf2, the DOS vector no longer exists (at least not in this form): https://github.com/django/django/commit/68540fe4df44492571bc610a0a043d3d02b3d320 On Thursday, October 3, 2013 9:56:14 AM UTC+2, Ram Rachum wrote: > > Hi everybody, > > I've submitted the patch, and corrected it, and it's been sitting on the > issue tracker for 2 weeks without anyone commenting. Does anyone care to > discuss this? I want to have this merged in, or discuss any problems in > merging it in. > > > On Sun, Sep 15, 2013 at 11:27 PM, 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 >>> 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 a topic in the >> Google Groups "Django developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/django-developers/iuSE5Y4R3hg/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/48f1d111-e8e0-4c16-bec3-1af1cd1aa1f9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Idea about authentication
Hi everybody, I've submitted the patch, and corrected it, and it's been sitting on the issue tracker for 2 weeks without anyone commenting. Does anyone care to discuss this? I want to have this merged in, or discuss any problems in merging it in. On Sun, Sep 15, 2013 at 11:27 PM, 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 >> 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 a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/iuSE5Y4R3hg/unsubscribe > . > To unsubscribe from this group and all its topics, 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. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANXboVazQU4bF_vBtD4y0vxq54mkcjrR-ZaFknmpuyJrFRHMEw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Idea about authentication
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 >> 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 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.
Re: Idea about authentication
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 > > > 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 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.
Re: Idea about authentication
On Sep 15, 2013, at 2:59 PM, Florian Apolloner 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Idea about authentication
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). Florian -- 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.
Re: Idea about authentication
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 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 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
Re: Idea about authentication
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. I'm proposing to keep that time just as long, but make it independent on the password length. On Sunday, September 15, 2013 1:12:31 PM UTC+3, Florian Apolloner wrote: > > > > On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote: > >> 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. >> > > PBKDF2 takes long by design… A better long term solution would be to rate > limit password attempts… > -- 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.
Re: Idea about authentication
On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote: > 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. > PBKDF2 takes long by design… A better long term solution would be to rate limit password attempts… -- 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.
Re: Idea about authentication
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 >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.
Re: Idea about authentication
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 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-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. > -- 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.
Idea about authentication
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-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.
