[Cryptography] The problem is not just merely a secure KDF (was "Serious paranoia...")

[Kevin W. Wall]

On Thu, Dec 26, 2013 at 7:02 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Thu, Dec 26, 2013 at 09:14:34PM +0100, Krisztián Pintér 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
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140103/89ef9e03/attachment.html>