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

[Bill Cox]

On Sat, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <
cryptography at patrickmylund.com> wrote:

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

I don't understand why servers do the KDF rather than the client.  The
current system requires that the password be transmitted to the server, and
users have to trust the service provider to be honest.  This provides a
couple ways for attackers to compromise the password.  Just pay off the
guys running the server ($10M anyone?), issue them a court order of some
sort, or override the CA and do the man-in-the-middle thing.  As soon as
you transmit your password to the server, security is already broken.

With client-side KDF, the DDoS issue goes away, the servers have a far
lighter load, and users get real password security.  Why is the current
flawed system used?  I just don't understand it.


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

The guys in charge of mainstream crypto algorithms don't seem to be doing
KDFs very well.  It's not just the lame server-side KDFs.  The one that
really bothers me is TrueCrypt, which in user-land is more popular than all
the rest combined by a factor of several.  About 90% of all file encryption
in user-land (not corporate or server side) is done in TrueCrypt.

I've scanned through the code, and the strongest KDF you can select is 2000
rounds of AES-512.  By default it uses something far weaker.  From BitCoin,
we learned that custom hardware can deliver SHA-256 hashing at a rate of 1
giga-hash/second for $10.  If you have on the order of $1B to spend, you
can do 10^17 SHA-256 hashes per second or 10^16 SHA-512 hashes.  A $1B
machine could do close to 10^13 KDFs/second of TrueCrypt's strongest KDF.
 Given that the NSA only claims to be able to do something like 1T password
guesses/second, TrueCrypt's max KDF seems to provide little additional
security, at least against custom hardware guessing machines.

In addition to a weak KDF, users are encouraged to use weak passwords.  For
example, https://howsecureismypassword.net/ says that "dogs breakfast"
would take a desktop PC a million years to crack.  My Huffman Code password
compressor represents this pass phrase as 011011101110010 1110111101011110
- 31 bits.  My password cracker on a PC would guess this password in about
2 billion attempts, or about 70 years if each guess required a full second
of KDF  With the weak TrueCrypt KDF (about 50 milliseconds on a PC), that
drops to 3.5 years.  With a graphics card, that drops to days, not years.
 At 1T password guesses per second, this password would be cracked in 2
milliseconds!

A $1,000 PC might do 50,000 SHA-512 hashes/second, while for $20, I can do
1e9 AES-512 hashes/second with an ASIC.  Why give attackers a free factor
of a million advantage for using custom hardware?  Why do we even quote
password strength in terms of how long a PC would tack to crack it?  Simply
switching to scrypt reduces the cost advantage of custom hardware from a
million to maybe 100.  Done right, we could reduce it to 10 or less.  I
just don't understand how these guys can live with weak key stretching.  At
a minimum, they should let users select the number of iterations for the
SHA-512 KDF.  GPG at least does that.  I'm suspicious there may be some
cash being paid to the right people to make sure TrueCrypt key stretching
stays weak.  If RSA got $10M, what did the TrueCrypt guys get?  Simply
adding an option for user-selectable rounds of key stretching would take
about 10 minutes of coding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131221/7abb699c/attachment.html>