[148564] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Bill Cox)
Sun Dec 22 01:38:15 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAEw2jfz68JVcU5tixAz609Z2bRXSqHO_8fQ7oKL70475=+BGaA@mail.gmail.com>
Date: Sat, 21 Dec 2013 23:46:59 -0500
From: Bill Cox <waywardgeek@gmail.com>
To: Patrick Mylund Nielsen <cryptography@patrickmylund.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============7673788166950216623==
Content-Type: multipart/alternative; boundary=047d7b3a9cb09a456304ee1833d7

--047d7b3a9cb09a456304ee1833d7
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <
cryptography@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.

--047d7b3a9cb09a456304ee1833d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <span dir=3D"ltr">&lt;<=
a href=3D"mailto:cryptography@patrickmylund.com" target=3D"_blank">cryptogr=
aphy@patrickmylund.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">The most popular argu=
ment against something like scrypt seems to be that using an expensive func=
tion makes you susceptible to DDoS attacks. This is true, but it&#39;s also=
 completely beside the point.</span><br>
</div></div></div></div></blockquote><div><br></div><div>I don&#39;t unders=
tand why servers do the KDF rather than the client. =A0The current system r=
equires that the password be transmitted to the server, and users have to t=
rust the service provider to be honest. =A0This provides a couple ways for =
attackers to compromise the password. =A0Just pay off the guys running the =
server ($10M anyone?), issue them a court order of some sort, or override t=
he CA and do the man-in-the-middle thing. =A0As soon as you transmit your p=
assword to the server, security is already broken.</div>
<div><br></div><div>With client-side KDF, the DDoS issue goes away, the ser=
vers have a far lighter load, and users get real password security. =A0Why =
is the current flawed system used? =A0I just don&#39;t understand it.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<div><div>Similarly, the people who do know better owe it to the average co=
nsumer to be advocates for things like KDFs in password authentication cons=
tructions, even if they are old and unsexy concepts.<br></div>
</div>
</div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">The guys in charge =
of mainstream crypto algorithms don&#39;t seem to be doing KDFs very well. =
=A0It&#39;s not just the lame server-side KDFs. =A0The one that really both=
ers me is TrueCrypt, which in user-land is more popular than all the rest c=
ombined by a factor of several. =A0About 90% of all file encryption in user=
-land (not corporate or server side) is done in TrueCrypt.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I&#39;ve sc=
anned through the code, and the strongest KDF you can select is 2000 rounds=
 of AES-512. =A0By default it uses something far weaker. =A0From BitCoin, w=
e learned that custom hardware can deliver SHA-256 hashing at a rate of 1 g=
iga-hash/second for $10. =A0If you have on the order of $1B to spend, you c=
an do 10^17 SHA-256 hashes per second or 10^16 SHA-512 hashes. =A0A $1B mac=
hine could do close to 10^13 KDFs/second of TrueCrypt&#39;s strongest KDF. =
=A0Given that the NSA only claims to be able to do something like 1T passwo=
rd guesses/second, TrueCrypt&#39;s max KDF seems to provide little addition=
al security, at least against custom hardware guessing machines.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In addition=
 to a weak KDF, users are encouraged to use weak passwords. =A0For example,=
=A0<a href=3D"https://howsecureismypassword.net/">https://howsecureismypass=
word.net/</a>=A0says that &quot;dogs breakfast&quot; would take a desktop P=
C a million years to crack. =A0My Huffman Code password compressor represen=
ts this pass phrase as=A0011011101110010=A01110111101011110 - 31 bits. =A0M=
y password cracker on a PC would guess this password in about 2 billion att=
empts, or about 70 years if each guess required a full second of KDF =A0Wit=
h the weak TrueCrypt KDF (about 50 milliseconds on a PC), that drops to 3.5=
 years. =A0With a graphics card, that drops to days, not years. =A0At 1T pa=
ssword guesses per second, this password would be cracked in 2 milliseconds=
!</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">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. =A0Why give attackers a free factor of a milli=
on advantage for using custom hardware? =A0Why do we even quote password st=
rength in terms of how long a PC would tack to crack it? =A0Simply switchin=
g to scrypt reduces the cost advantage of custom hardware from a million to=
 maybe 100. =A0Done right, we could reduce it to 10 or less. =A0I just don&=
#39;t understand how these guys can live with weak key stretching. =A0At a =
minimum, they should let users select the number of iterations for the SHA-=
512 KDF. =A0GPG at least does that. =A0I&#39;m suspicious there may be some=
 cash being paid to the right people to make sure TrueCrypt key stretching =
stays weak. =A0If RSA got $10M, what did the TrueCrypt guys get? =A0Simply =
adding an option for user-selectable rounds of key stretching would take ab=
out 10 minutes of coding.</div>
</div>

--047d7b3a9cb09a456304ee1833d7--

--===============7673788166950216623==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7673788166950216623==--

home help back first fref pref prev next nref lref last post