5 ms·

> Doing all the stretching work on a server scales poorly. And predicting how many users will try to log in is impossible, unless you set up drastic limits. One

> Doing all the stretching work on a server scales poorly. And predicting how many users will try to log in is impossible, unless you set up drastic limits. One way or the other, this makes the whole service vulnerable to very cheap denial of service attacks. Can you point to an example of a (nontrivial) site where a DoS attack against the password hashing service was the primary point of failure? I'm sure it's happened, but it strikes me that most systems will go down hardest and first from pressure on other parts of that system. > This also has the advantage that the server doesn't see the actual password. This is the more compelling thing, to me, about this approach. Doesn't play super nicely with the established API tooling out there, but it's something to consider.

jedisct1 9y ago
> Can you point to an example of a (nontrivial) site where a DoS attack against the password hashing service was the primary point of failure? Reformulating the question from a different angle: why did all the large sites whose password database got leaked (Yahoo, LinkedIn...) still use regular hash functions? > This also has the advantage that the server doesn't see the actual password. Other schemes with that property include augmented PAKEs such as SPAKE2+ (example implementation: https://github.com/jedisct1/spake2-ee https://github.com/jedisct1/spake2-ee) and Tabby PAKE (https://github.com/catid/tabby/blob/master/PASSWORD.md https://github.com/catid/tabby/blob/master/PASSWORD.md)
- tjoff 9y ago
  > Reformulating the question from a different angle: why did all the large sites whose password database got leaked (Yahoo, LinkedIn...) still use regular hash functions? Incompetence.
- eropple 9y ago
  > why did all the large sites whose password database got leaked (Yahoo, LinkedIn...) still use regular hash functions? Inertia? Stuff I built in 2001 probably still uses MD5+salt today because nobody's maintained it in over a decade. Fear of breakage? Going down because of an "unnecessary" change probably reads worse to management than getting owned does (before it happens)--and besides, it's not our data, just users. I dunno, man. Obviously I have a ton of respect for your crypto work (I mean that, seriously, thank you). Your other points make total sense, this one just feels like overreach > Other schemes with that property Well outside my weight class, but you've given me some stuff to read about. No idea how it ends up integrating with existing API tooling, but worth examining for sure.
grw_ 9y ago
> Can you point to an example of a (nontrivial) site where a DoS attack against the password hashing service was the primary point of failure? Here's a vulnerability report from the Django framework where arbitrarily-large passwords could be submitted for checking, tying up server resources in a DoS attack: https://www.djangoproject.com/weblog/2013/sep/15/security/ https://www.djangoproject.com/weblog/2013/sep/15/security/ I'm not sure any real-world sites were affected by this, but had the patch not been applied it certainly would have been possible.

jedisct1 9y ago

> Can you point to an example of a (nontrivial) site where a DoS attack against the password hashing service was the primary point of failure? Reformulating the question from a different angle: why did all the large sites whose password database got leaked (Yahoo, LinkedIn...) still use regular hash functions? > This also has the advantage that the server doesn't see the actual password. Other schemes with that property include augmented PAKEs such as SPAKE2+ (example implementation: https://github.com/jedisct1/spake2-ee https://github.com/jedisct1/spake2-ee) and Tabby PAKE (https://github.com/catid/tabby/blob/master/PASSWORD.md https://github.com/catid/tabby/blob/master/PASSWORD.md)

tjoff 9y ago
> Reformulating the question from a different angle: why did all the large sites whose password database got leaked (Yahoo, LinkedIn...) still use regular hash functions? Incompetence.
eropple 9y ago
> why did all the large sites whose password database got leaked (Yahoo, LinkedIn...) still use regular hash functions? Inertia? Stuff I built in 2001 probably still uses MD5+salt today because nobody's maintained it in over a decade. Fear of breakage? Going down because of an "unnecessary" change probably reads worse to management than getting owned does (before it happens)--and besides, it's not our data, just users. I dunno, man. Obviously I have a ton of respect for your crypto work (I mean that, seriously, thank you). Your other points make total sense, this one just feels like overreach > Other schemes with that property Well outside my weight class, but you've given me some stuff to read about. No idea how it ends up integrating with existing API tooling, but worth examining for sure.

grw_ 9y ago

> Can you point to an example of a (nontrivial) site where a DoS attack against the password hashing service was the primary point of failure? Here's a vulnerability report from the Django framework where arbitrarily-large passwords could be submitted for checking, tying up server resources in a DoS attack: https://www.djangoproject.com/weblog/2013/sep/15/security/ https://www.djangoproject.com/weblog/2013/sep/15/security/ I'm not sure any real-world sites were affected by this, but had the patch not been applied it certainly would have been possible.