[Cryptography] Why don't we protect passwords properly?

[Patrick Mylund Nielsen]

On Fri, Dec 20, 2013 at 11:00 PM, Bill Cox <waywardgeek at gmail.com> wrote:

> SHA-XXX (all of them) seem to have been designed specifically to be cheap
> and fast to compute in custom hardware, while taking forever to compute on
> modern CPUs.


An ASIC is always faster. It's only a problem if the algorithm is widely
used and the public doesn't have access to hardware implementations. For
something like AES, this isn't true.

The main principle behind password-based KDFs like scrypt is to make
building ASICs to efficiently crack a digest database prohibitively
expensive.


> Scrypt, used by FreeCoin, shows how to do truly effective key stretching,


I'm really positively surprised to read this sentence. I would have never
expected cryptocurrencies to be a reason people started talking about using
expensive KDFs for something like password authentication.


> I want a straight answer, and I truly don't know what it is.  Is it scary
> tall dudes in dark suits, or seriously ignorant devs?
>

It's hard to believe there was a conspiracy. Too many people who have no
relation to each other would have to be involved

It's much more likely that forcing an adversary to require more die area,
and thus pay more for an ASIC to break something, is a plainly unsexy
concept to most developers; that it's more of a failure of marketing than
anything else. (That applies at the other end of the scale, too: Most
professional cryptographers consider this a solved problem, so very few
work on it.)

There are people who really should know better: IETF WG members, for
example, who to this day submit drafts with password authentication
mechanisms that amount to two iterations of SHA-256(salt+pwd.) That is
inexcusable ignorance. But for the majority of developers, it's probably
just that most don't know that there is a better way, and since there is no
de facto library available to handle this stuff, they're forced to invent
their own. (The closest to a standard has probably been bcrypt, which owes
its success, at least in my opinion, to its extremely accessible API.)

The most popular argument against something like scrypt seems to be that
using an expensive function makes you susceptible to DDoS attacks. This is
true, but it's also completely beside the point. Think about it: everything
you do--database queries, template rendering, etc.--incurs overhead, so the
solution isn't to make your password digest database weaker, but to prevent
malicious users from doing those things over and over. (And if your
application is really so big that *legitimate* logins are a DDoS concern,
then you should be able to handle it without compromising user security by
adding more hardware.)

Unfortunately, there are many programmers that share your attitude that
crypto is way cool, but *don't* spend anywhere near enough time actually
studying it before making the next big privacy-preserving social
application with "military-grade AES 256-bit security." If they did, I
think we'd see a lot more scrypt, bcrypt, PBKDF2, SRP, etc., and much fewer
homegrown, ineffective contraptions.

Similarly, the people who do know better owe it to the average consumer to
be advocates for things like KDFs in password authentication constructions,
even if they are old and unsexy concepts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131221/424df17e/attachment.html>