[148580] in cryptography@c2.net mail archive
Re: [Cryptography] Why don't we protect passwords properly?
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Sun Dec 22 16:15:23 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <CAOLP8p7LFthi=ABTQMWgh=jkNwta6Hui0d_+JQBgM5iPpgg-=g@mail.gmail.com>
Date: Sun, 22 Dec 2013 11:26:30 -0500
To: Bill Cox <waywardgeek@gmail.com>
Cc: Patrick Mylund Nielsen <cryptography@patrickmylund.com>,
"cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8512722560844871899==
Content-Type: multipart/alternative; boundary="Apple-Mail=_D8EE5D37-EAC2-401C-8BFA-82F6BAAAD2F2"
--Apple-Mail=_D8EE5D37-EAC2-401C-8BFA-82F6BAAAD2F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
On Dec 21, 2013, at 11:46 PM, Bill Cox wrote:
> I don't understand why servers do the KDF rather than the client.
There's an old joke: How could God create the entire universe in only =
six days? No installed base!
It's also *so* easy to criticize yesterday's decisions based on today's =
knowledge and capabilities.
KDF's used specifically to strengthen weak user passwords against =
brute-force attack were introduced as a quick way to strengthen =
*existing* systems with immense numbers of already-fielded clients. =
Requiring that the clients all change would be a perfect way to make =
sure nothing got improved.
Keep in mind that the *original* purpose of "key hashing" was rather =
different: It was to keep passwords secure even when the password file =
(or logical equivalent) was leaked. Password hashing was introduced in =
early versions of Unix with exactly this primary purpose - and the =
secondary purpose of allowing anyone to verify a password by reading the =
public value from the file, hashing an incoming alleged password, and =
comparing. It took a number of years to learn that making even the =
hashed passwords public was a bad idea - and every Unix system in =
decades has had shadow password files. Web servers and such simply =
followed (often badly) existing "best practice": Unix password hashing =
was based on DES; they moved to more recent crypto standards. Of =
course, then they (the Web server community as a whole) screwed up the =
entire ecosystem by implementing such poor security that they repeatedly =
managed to lose huge databases full of millions of hashed passwords.
The ability to do mass off-line attacks wasn't anticipated. Its success =
was based on the combination of several things that would have been hard =
to predict: Clever fast implementations of some of the primitives =
optimized for the purpose of password cracking rather than ordinary =
cryptography - e.g., doing encryption in bit-wise parallel; the ability =
to utilize large numbers of machines for password cracking purpose, =
whether on a service like AWS or through botnets of ever growing size; =
the wide deployment of graphics cards, which it turned out could be used =
to implement cracking algorithms very quickly - and of course the =
availability of all those databases of encrypted passwords, some of =
which didn't even bother to use salts, which was best practice by the =
late 1970's.
All this didn't come together until the last 2-3 years or so. There =
simply were no plausible, much less *demonstrated*, large scale attacks =
against encrypted passwords until not long before that. bcrypt was =
first published in 1999 specifically to protect against rainbow tables - =
a neat theoretical attack that may never have actually been used in =
practice anywhere. (The newer brute force techniques are much more =
practical than rainbow tables in today's environment; if you hear =
someone talking about using rainbow tables today, it probably means they =
don't know what they are talking about.) scrypt is 10 years more recent =
- the paper defining it was only published in 2009, and a =
(since-expired) draft RFC dates to 2012. Most cryptographers would =
probably be leery of scrypt: It simply hasn't been around long enough, =
and survived enough concerted attacks by those who are really good at =
such attacks, to form a good judgement as to its strength. Just because =
all publicly known implementations are slow doesn't mean there aren't =
fast ones waiting to be found.
Using a strong key hashing function (I hesitate to say KDF because KDF's =
have other purposes as well) on the server as a replacement for its =
existing hash function is a quick fix that doesn't require any changes =
to clients and minimal changes to servers (of which there are quite a =
few as well). There are no other measures that could be applied in =
anything less than years. (And, in practice, even this substitution is =
moving rather slowly.)
It's also worth pointing out that strong hashing on the client is a =
non-starter for another reason: Not all clients are fast workstations. =
In fact, increasing they are mobile phones and tablets, which have =
limited computing capability and, more to the point, are heavily power =
constrained. I'm not aware of any measurements, but I'd guess that =
bcrypt - and especially scrypt, which by design hits memory very hard - =
use a *lot* of power.
> 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.
That makes no sense. If you transmit the derived key, *it* becomes the =
"real" key. The server has to know it - either all the time (if service =
providers decide that since clients are doing the hashing they don't =
need to bother) or, as now, every time you log in. The only difference =
is that if you re-use a password across sites, currently you may be =
handing server A your password to server B. To which the answer, as =
always, is "don't do that". If you're assuming significant changes on =
the client side, you would do better "assuming in" an =
already-well-developed technology: Password managers, which make it =
trivial to generate different passwords for every site.
Alternatively, if you're assuming the whole system changes, PAKE schemes =
like EKE(1992!) or SPF(RFC2945, 2000!) - are better anyway.
> 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.
TrueCrypt was released in 2004, well before the style of attack you're =
so concerned about was known. Hey, guess what: TrueCrypt is open =
source. If you think you can improve it by adding a better "password =
stretcher" - by all means do so. You can even do it without touching =
the main TrueCrypt code by adding a wrapper around the code that reads =
the password. There are no magic "guys in charge" to tell you not to do =
it.
> 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.
Someone is wrong on the Internet! Where will it end?
> 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?
And a new conspiracy theory!
> Simply adding an option for user-selectable rounds of key stretching =
would take about 10 minutes of coding.
a) So do it! I'll bet writing your email took longer than that.
b) It's been shown repeatedly that adding options - especially options =
that people won't even understand - doesn't help. Almost everyone will =
choose the default. You have to make the default "right". In the world =
of crypto, "right" today almost always becomes "wrong" a couple of years =
down the road as attacks keep getting better.
-- Jerry
--Apple-Mail=_D8EE5D37-EAC2-401C-8BFA-82F6BAAAD2F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Dec 21, 2013, at 11:46 PM, Bill Cox =
wrote:</div><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I don't understand =
why servers do the KDF rather than the =
client.</div></div></div></div></blockquote><div>There's an old joke: =
How could God create the entire universe in only six days? =
No installed base!</div><div><br></div><div>It's also *so* easy to =
criticize yesterday's decisions based on today's knowledge and =
capabilities.</div><div><br></div><div>KDF's used specifically to =
strengthen weak user passwords against brute-force attack were =
introduced as a quick way to strengthen *existing* systems with immense =
numbers of already-fielded clients. Requiring that the clients all =
change would be a perfect way to make sure nothing got =
improved.</div><div><br></div><div>Keep in mind that the *original* =
purpose of "key hashing" was rather different: It was to keep =
passwords secure even when the password file (or logical equivalent) was =
leaked. Password hashing was introduced in early versions of Unix =
with exactly this primary purpose - and the secondary purpose of =
allowing anyone to verify a password by reading the public value from =
the file, hashing an incoming alleged password, and comparing. It =
took a number of years to learn that making even the hashed passwords =
public was a bad idea - and every Unix system in decades has had shadow =
password files. Web servers and such simply followed (often badly) =
existing "best practice": Unix password hashing was based on DES; =
they moved to more recent crypto standards. Of course, then they =
(the Web server community as a whole) screwed up the entire ecosystem by =
implementing such poor security that they repeatedly managed to lose =
huge databases full of millions of hashed =
passwords.</div><div><br></div><div>The ability to do mass off-line =
attacks wasn't anticipated. Its success was based on the =
combination of several things that would have been hard to predict: =
Clever fast implementations of some of the primitives optimized =
for the purpose of password cracking rather than ordinary cryptography - =
e.g., doing encryption in bit-wise parallel; the ability to utilize =
large numbers of machines for password cracking purpose, whether on a =
service like AWS or through botnets of ever growing size; the wide =
deployment of graphics cards, which it turned out could be used to =
implement cracking algorithms very quickly - and of course the =
availability of all those databases of encrypted passwords, some of =
which didn't even bother to use salts, which was best practice by the =
late 1970's.</div><div><br></div><div>All this didn't come together =
until the last 2-3 years or so. There simply were no plausible, =
much less *demonstrated*, large scale attacks against encrypted =
passwords until not long before that. bcrypt was first published =
in 1999 specifically to protect against rainbow tables - a neat =
theoretical attack that may never have actually been used in practice =
anywhere. (The newer brute force techniques are much more =
practical than rainbow tables in today's environment; if you hear =
someone talking about using rainbow tables today, it probably means they =
don't know what they are talking about.) scrypt is 10 years more =
recent - the paper defining it was only published in 2009, and a =
(since-expired) draft RFC dates to 2012. Most cryptographers would =
probably be leery of scrypt: It simply hasn't been around long =
enough, and survived enough concerted attacks by those who are really =
good at such attacks, to form a good judgement as to its strength. =
Just because all publicly known implementations are slow doesn't =
mean there aren't fast ones waiting to be =
found.</div><div><br></div><div>Using a strong key hashing function (I =
hesitate to say KDF because KDF's have other purposes as well) on the =
server as a replacement for its existing hash function is a quick fix =
that doesn't require any changes to clients and minimal changes to =
servers (of which there are quite a few as well). There are no =
other measures that could be applied in anything less than years. =
(And, in practice, even this substitution is moving rather =
slowly.)</div><div><br></div><div>It's also worth pointing out that =
strong hashing on the client is a non-starter for another reason: =
Not all clients are fast workstations. In fact, increasing =
they are mobile phones and tablets, which have limited computing =
capability and, more to the point, are heavily power constrained. =
I'm not aware of any measurements, but I'd guess that bcrypt - and =
especially scrypt, which by design hits memory very hard - use a *lot* =
of power.</div><div><br></div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div> =
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.</div></div></div></div></blockquote>That makes no sense. =
If you transmit the derived key, *it* becomes the "real" key. =
The server has to know it - either all the time (if service =
providers decide that since clients are doing the hashing they don't =
need to bother) or, as now, every time you log in. The only =
difference is that if you re-use a password across sites, currently you =
may be handing server A your password to server B. To which the =
answer, as always, is "don't do that". If you're assuming =
significant changes on the client side, you would do better "assuming =
in" an already-well-developed technology: Password managers, which =
make it trivial to generate different passwords for every =
site.</div><div><br></div><div>Alternatively, if you're assuming the =
whole system changes, PAKE schemes like EKE(1992!) or SPF(RFC2945, =
2000!) - are better anyway.</div><div><br></div><div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra">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.</div></div></blockquote>TrueCrypt was released in 2004, well =
before the style of attack you're so concerned about was known. =
Hey, guess what: TrueCrypt is open source. If you =
think you can improve it by adding a better "password stretcher" - by =
all means do so. You can even do it without touching the main =
TrueCrypt code by adding a wrapper around the code that reads the =
password. There are no magic "guys in charge" to tell you not to =
do it.</div><div><br></div><div><blockquote type=3D"cite"><div =
dir=3D"ltr"><div class=3D"gmail_extra">In addition to a weak KDF, users =
are encouraged to use weak passwords. For example, <a =
href=3D"https://howsecureismypassword.net/">https://howsecureismypassword.=
net/</a> says that "dogs breakfast" would take a desktop PC a =
million years to crack.</div></div></blockquote>Someone is wrong on the =
Internet! Where will it end?</div><div><br></div><div><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra">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?</div></div></blockquote><div>And a new conspiracy =
theory!</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra">Simply adding an option for user-selectable rounds =
of key stretching would take about 10 minutes of coding.</div>
</div></blockquote>a) So do it! I'll bet writing your email =
took longer than that.</div><div>b) It's been shown repeatedly =
that adding options - especially options that people won't even =
understand - doesn't help. Almost everyone will choose the =
default. You have to make the default "right". In the world =
of crypto, "right" today almost always becomes "wrong" a couple of years =
down the road as attacks keep getting better.</div><div><div> =
=
=
-- =
Jerry</div><div><br></div></div><br></body></html>=
--Apple-Mail=_D8EE5D37-EAC2-401C-8BFA-82F6BAAAD2F2--
--===============8512722560844871899==
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
--===============8512722560844871899==--
