<div dir="ltr"><div class="gmail_extra">On Thu, Dec 26, 2013 at 7:02 PM, Theodore Ts'o <span dir="ltr"><<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Dec 26, 2013 at 09:14:34PM +0100, Krisztián Pintér 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<br>
> 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.  So 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.  But 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.  The cost and<br>
the benefits for making this change are quite different.<br></blockquote></div><br><div class="gmail_default" style="font-family:courier new,monospace">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 sufficiently secure KDF. Scrypt has been<br>around for awhile, and bcrypt before that. And PBKDF2<br></div><div class="gmail_default" style="font-family:courier new,monospace">
has been an RFC since 2000 (see RFC 2898). But if you<br>take a look, you'll see that these are seldom used.<br></div><div class="gmail_default" style="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="gmail_default" style="font-family:courier new,monospace">is SHA1 or salted SHA1 passwords. Why is this the case?<br></div><div class="gmail_default" style="font-family:courier new,monospace">
Well, I think there are 2 reasons. First is that the<br></div><div class="gmail_default" style="font-family:courier new,monospace">most COTS software that handles password-based authN<br></div><div class="gmail_default" style="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 scrypt or PBKDF2 with<br></div><div class="gmail_default" style="font-family:courier new,monospace">
LDAP, you generally are SOL. (And while one could add<br></div><div class="gmail_default" style="font-family:courier new,monospace">code to support a new system...most directory servers<br>have C or C++ APIs, most developers no longer wish to<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">touch C or C++.)  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="gmail_default" style="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="gmail_default" style="font-family:courier new,monospace">
against this DB, so if you change how the passwords are<br>stored, say to something 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 will be<br>
in "maintenance only" mode (no active development and<br>not assigned development team) and they will generally<br></div><div class="gmail_default" style="font-family:courier new,monospace">be across at least 2 different LOBs within the company,<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">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="gmail_default" style="font-family:courier new,monospace">forcing some million plus customers to change their<br>passwords so it has to be done rather cleverly.)<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
So sometimes, it is just a business decision not to change<br></div><div class="gmail_default" style="font-family:courier new,monospace">or the company is waiting on their vendor to support something<br>better than SHA1 or salted SHA1.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace">-kevin<br></div>--<br>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.blogspot.com/</a><br>
NSA: All your crypto bit are belong to us<div class="gmail_default" style="font-family:courier new,monospace;display:inline">.</div>
</div></div>