[148559] in cryptography@c2.net mail archive
Re: [Cryptography] Why don't we protect passwords properly?
daemon@ATHENA.MIT.EDU (Patrick Mylund Nielsen)
Sat Dec 21 19:00:05 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52B5125D.1020107@gmail.com>
Date: Sat, 21 Dec 2013 18:07:45 -0500
From: Patrick Mylund Nielsen <cryptography@patrickmylund.com>
To: Bill Cox <waywardgeek@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8923155672966566700==
Content-Type: multipart/alternative; boundary=001a11c2b89871b1ca04ee13760f
--001a11c2b89871b1ca04ee13760f
Content-Type: text/plain; charset=UTF-8
On Fri, Dec 20, 2013 at 11:00 PM, Bill Cox <waywardgeek@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.
--001a11c2b89871b1ca04ee13760f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 20, 2013 at 11:00 PM, Bill Cox <span dir=3D"ltr"><<a href=3D"mai=
lto:waywardgeek@gmail.com" target=3D"_blank">waywardgeek@gmail.com</a>><=
/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">SHA-XXX (all of them) seem to have been designed specifica=
lly to be cheap and fast to compute in custom hardware, while taking foreve=
r to compute on modern CPUs. </blockquote>
<div><br></div><div>An ASIC is always faster. It's only a problem if th=
e algorithm is widely used and the public doesn't have access to hardwa=
re implementations. For something like AES, this isn't true.</div>
<div><br></div><div>The main principle behind password-based KDFs like scry=
pt is to make building ASICs to efficiently crack a digest database prohibi=
tively expensive.</div>
<div>=C2=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-l=
eft-style:solid;padding-left:1ex">
Scrypt, used by FreeCoin, shows how to do truly effective key stretching,</=
blockquote><div><br></div><div>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 passwo=
rd authentication.</div>
<div>=C2=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-l=
eft-style:solid;padding-left:1ex">I want a straight answer, and I truly don=
't know what it is. =C2=A0Is it scary tall dudes in dark suits, or seri=
ously ignorant devs?<br>
</blockquote><div><br></div><div>It's hard to believe there was a consp=
iracy. Too many people who have no relation to each other would have to be =
involved</div><div><br></div><div>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 m=
ore of a failure of marketing than anything else. (That applies at the othe=
r end of the scale, too: Most professional cryptographers consider this a s=
olved problem, so very few work on it.)</div>
<div><br></div><div>There are people who really should know better: IETF WG=
members, for example, who to this day submit drafts with password authenti=
cation mechanisms that amount to two iterations of SHA-256(salt+pwd.) That =
is inexcusable ignorance. But for the majority of developers, it's prob=
ably just that most don't know that there is a better way, and since th=
ere is no de facto library available to handle this stuff, they're forc=
ed 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 accessib=
le API.)</div>
<div><br></div><div>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. Thin=
k about it: everything you do--database queries, template rendering, etc.--=
incurs overhead, so the solution isn't to make your password digest dat=
abase weaker, but to prevent malicious users from doing those things over a=
nd 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 compromis=
ing user security by adding more hardware.)</div>
<div><br></div><div><div>Unfortunately, there are many programmers that sha=
re your attitude that crypto is way cool, but *don't* spend anywhere ne=
ar enough time actually studying it before making the next big privacy-pres=
erving social application with "military-grade AES 256-bit security.&q=
uot; If they did, I think we'd see a lot more scrypt, bcrypt, PBKDF2, S=
RP, etc., and much fewer homegrown, ineffective contraptions.</div>
<div><br></div><div>Similarly, the people who do know better owe it to the =
average consumer to be advocates for things like KDFs in password authentic=
ation constructions, even if they are old and unsexy concepts.</div>
</div>
</div></div></div>
--001a11c2b89871b1ca04ee13760f--
--===============8923155672966566700==
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
--===============8923155672966566700==--
