3 ms·

> 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 th

> 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.