[148886] in cryptography@c2.net mail archive
[Cryptography] The problem is not just merely a secure KDF (was
daemon@ATHENA.MIT.EDU (Kevin W. Wall)
Fri Jan 3 01:19:18 2014
X-Original-To: cryptography@metzdowd.com
Date: Fri, 3 Jan 2014 00:10:34 -0500
From: "Kevin W. Wall" <kevin.w.wall@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: =?ISO-8859-1?Q?Kriszti=E1n_Pint=E9r?= <pinterkr@gmail.com>,
Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============1845200295654584286==
Content-Type: multipart/alternative; boundary=bcaec520f3050b47ec04ef09eede
--bcaec520f3050b47ec04ef09eede
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, Dec 26, 2013 at 7:02 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Thu, Dec 26, 2013 at 09:14:34PM +0100, Kriszti=E1n Pint=E9r wrote:
> > obviously, these are very contrived situations. but far from being
> > impossible. the question is not whether it is an issue or not. the
> > question is, how serious the threat is and what can we do about it. if
> > the solution is costly, we might accept the threat as a trade off, for
> > the time being. but it does not make the issue nonexistent. we can
> > still aspire to find a solution that does not have this attack angle.
> > we should aspire.
> >
> > and that was my point. i would like to see an algorithm that is memory
> > hard, but the data written to the memory is scrambled by some random
> > parameter. i can design such an algorithm, it is not that hard. the
> > problem is, we need to do that effectively and in a way that does not
> > grant advantage to the bad guys.
>
> I think the creation of such an algorithm would make for a wonderful
> academic publication, and I would think it meets the "minimal
> publishable unit" that academic publishing venues and tenure boards
> care about. So certainly, having an algorithm which has certain
> superior characteristics, such as being hard to brute force back to
> text password even in the face of hardware acceleration, protection
> from cache attacks and swap attacks, etc., would certainly be better
> than a KDF that doesn't have these properties.
>
> There is a separate question, though, which is whether this threat is
> significant enough that it is changing the current deployed base to
> use it. But I don't think this is a discussion that can be made
> generally, which is how the discussion has been running on the list as
> of late --- for example, the subject line "Why don't we protect
> passwords properly?"
>
> I suspct the discussion would be more productive if it were more
> tightly focused --- for example, changing the string-to-key function
> used by ssh to protect its private key file, versus changing the
> string-to-key function for PPP CHAP authentication, etc. The cost and
> the benefits for making this change are quite different.
>
Sorry to jump in so late here, but I think the problem
of securely protecting stored passwords--at least when
used for authentication purposes-goes beyond merely
finding a sufficiently secure KDF. Scrypt has been
around for awhile, and bcrypt before that. And PBKDF2
has been an RFC since 2000 (see RFC 2898). But if you
take a look, you'll see that these are seldom used.
I would contend that it is not that security folks
are not aware of their benefits. Instead, what is used
is SHA1 or salted SHA1 passwords. Why is this the case?
Well, I think there are 2 reasons. First is that the
most COTS software that handles password-based authN
(notably LDAP directory servers) for the most part only
support the old DES-based crypt, SHA1, and salted SHA1
formats. So if you want to use scrypt or PBKDF2 with
LDAP, you generally are SOL. (And while one could add
code to support a new system...most directory servers
have C or C++ APIs, most developers no longer wish to
touch C or C++.) The second reason has to do with all
the legacy systems accessing the software. Most of the
authN systems that are weak at storing passwords are
interfacing to some sort of SQL database. Let's suppose
that this Db is storing customer passwords using something
like salted SHA1 format. Easy to change, right? Well,
maybe not. The problem is that in a F500 company you
may have a dozen or more different customer applications
that have all separately coded how to do the authN
against this DB, so if you change how the passwords are
stored, say to something like scrypt, then you have a
dozen or so applications to change. Further complicating
things is that about a third of those systems will be
in "maintenance only" mode (no active development and
not assigned development team) and they will generally
be across at least 2 different LOBs within the company,
making securing budget and coordinating a time to make
the cut from (say) salted SHA1 to scrypt that much more
difficult. (There is also the LOB resistance against
forcing some million plus customers to change their
passwords so it has to be done rather cleverly.)
So sometimes, it is just a business decision not to change
or the company is waiting on their vendor to support something
better than SHA1 or salted SHA1.
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us
.
--bcaec520f3050b47ec04ef09eede
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On Thu, Dec 26, 2013 at 7:02 PM=
, Theodore Ts'o <span dir=3D"ltr"><<a href=3D"mailto:tytso@mit.edu" =
target=3D"_blank">tytso@mit.edu</a>></span> wrote:<br><div class=3D"gmai=
l_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Dec 26, 2013 at 09=
:14:34PM +0100, Kriszti=E1n Pint=E9r wrote:<br>
> obviously, these are very contrived situations. but far from being<br>
> impossible. the question is not whether it is an issue or not. the<br>
> question is, how serious the threat is and what can we do about it. if=
<br>
> the solution is costly, we might accept the threat as a trade off, for=
<br>
> the time being. but it does not make the issue nonexistent. we can<br>
> still aspire to find a solution that does not have this attack angle.<=
br>
> we should aspire.<br>
><br>
> and that was my point. i would like to see an algorithm that is memory=
<br>
> hard, but the data written to the memory is scrambled by some random<b=
r>
> parameter. i can design such an algorithm, it is not that hard. the<br=
>
> problem is, we need to do that effectively and in a way that does not<=
br>
> grant advantage to the bad guys.<br>
<br>
</div>I think the creation of such an algorithm would make for a wonderful<=
br>
academic publication, and I would think it meets the "minimal<br>
publishable unit" that academic publishing venues and tenure boards<br=
>
care about. =A0So certainly, having an algorithm which has certain<br>
superior characteristics, such as being hard to brute force back to<br>
text password even in the face of hardware acceleration, protection<br>
from cache attacks and swap attacks, etc., would certainly be better<br>
than a KDF that doesn't have these properties.<br>
<br>
There is a separate question, though, which is whether this threat is<br>
significant enough that it is changing the current deployed base to<br>
use it. =A0But I don't think this is a discussion that can be made<br>
generally, which is how the discussion has been running on the list as<br>
of late --- for example, the subject line "Why don't we protect<br=
>
passwords properly?"<br>
<br>
I suspct the discussion would be more productive if it were more<br>
tightly focused --- for example, changing the string-to-key function<br>
used by ssh to protect its private key file, versus changing the<br>
string-to-key function for PPP CHAP authentication, etc. =A0The cost and<br=
>
the benefits for making this change are quite different.<br></blockquote></=
div><br><div class=3D"gmail_default" style=3D"font-family:courier new,monos=
pace">Sorry to jump in so late here, but I think the problem<br>of securely=
protecting stored passwords--at least when<br>
used for authentication purposes-goes beyond merely<br>finding a sufficient=
ly secure KDF. Scrypt has been<br>around for awhile, and bcrypt before that=
. And PBKDF2<br></div><div class=3D"gmail_default" style=3D"font-family:cou=
rier new,monospace">
has been an RFC since 2000 (see RFC 2898). But if you<br>take a look, you&#=
39;ll see that these are seldom used.<br></div><div class=3D"gmail_default"=
style=3D"font-family:courier new,monospace">I would contend that it is not=
that security folks<br>
are not aware of their benefits. Instead, what is used<br></div><div class=
=3D"gmail_default" style=3D"font-family:courier new,monospace">is SHA1 or s=
alted SHA1 passwords. Why is this the case?<br></div><div class=3D"gmail_de=
fault" style=3D"font-family:courier new,monospace">
Well, I think there are 2 reasons. First is that the<br></div><div class=3D=
"gmail_default" style=3D"font-family:courier new,monospace">most COTS softw=
are that handles password-based authN<br></div><div class=3D"gmail_default"=
style=3D"font-family:courier new,monospace">
(notably LDAP directory servers) for the most part only<br>support the old =
DES-based crypt, SHA1, and salted SHA1<br>formats. So if you want to use sc=
rypt or PBKDF2 with<br></div><div class=3D"gmail_default" style=3D"font-fam=
ily:courier new,monospace">
LDAP, you generally are SOL. (And while one could add<br></div><div class=
=3D"gmail_default" style=3D"font-family:courier new,monospace">code to supp=
ort a new system...most directory servers<br>have C or C++ APIs, most devel=
opers no longer wish to<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">touch C or C++.)=A0 The second reason has to do with all<br>the legacy =
systems accessing the software. Most of the<br>authN systems that are weak =
at storing passwords are<br>
interfacing to some sort of SQL database. Let's suppose<br>that this Db=
is storing customer passwords using something<br>like salted SHA1 format. =
Easy to change, right? Well,<br></div><div class=3D"gmail_default" style=3D=
"font-family:courier new,monospace">
maybe not. The problem is that in a F500 company you<br>may have a dozen or=
more different customer applications<br>that have all separately coded how=
to do the authN<br></div><div class=3D"gmail_default" style=3D"font-family=
:courier new,monospace">
against this DB, so if you change how the passwords are<br>stored, say to s=
omething like scrypt, then you have a<br>dozen or so applications to change=
. Further complicating<br>things is that about a third of those systems wil=
l be<br>
in "maintenance only" mode (no active development and<br>not assi=
gned development team) and they will generally<br></div><div class=3D"gmail=
_default" style=3D"font-family:courier new,monospace">be across at least 2 =
different LOBs within the company,<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">making securing budget and coordinating a time to make<br>the cut from =
(say) salted SHA1 to scrypt that much more<br>difficult. (There is also the=
LOB resistance against<br>
</div><div class=3D"gmail_default" style=3D"font-family:courier new,monospa=
ce">forcing some million plus customers to change their<br>passwords so it =
has to be done rather cleverly.)<br><br></div><div class=3D"gmail_default" =
style=3D"font-family:courier new,monospace">
So sometimes, it is just a business decision not to change<br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:courier new,monospace">or the co=
mpany is waiting on their vendor to support something<br>better than SHA1 o=
r salted SHA1.<br>
<br></div><div class=3D"gmail_default" style=3D"font-family:courier new,mon=
ospace">-kevin<br></div>--<br>Blog: <a href=3D"http://off-the-wall-security=
.blogspot.com/" target=3D"_blank">http://off-the-wall-security.blogspot.com=
/</a><br>
NSA: All your crypto bit are belong to us<div class=3D"gmail_default" style=
=3D"font-family:courier new,monospace;display:inline">.</div>
</div></div>
--bcaec520f3050b47ec04ef09eede--
--===============1845200295654584286==
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
--===============1845200295654584286==--
