RE: Source of bad password hashing practices? MySQL manual...

["Christey, Steven M." <coley () mitre org>]

The following is my personal opinion and does not represent any official MITRE CNA policy.

In this particular case, MySQL documentation is giving "bad advice" to application developers.  Any developer who 
follows this advice and publicly distributes a software product might be subject to a CVE for that particular 
application, depending on other factors that I'll get into momentarily.  While there are a couple CVEs for "bad 
documentation," I believe that those CVEs have always been relevant to a specific product for which the documentation 
was intended.

The act of "using MD5" likely affects thousands of products and would not necessarily be useful (or usable) to the 
general public if we had CVEs for every single product that uses MD5; yet, we are clearly in a transition point where 
stronger alternatives exist, attacks against MD5 are more realistic, etc.  Currently, we only have a handful of CVEs 
for "use of MD5," typically when the developer has made a stronger algorithm available.  We have a good number of CVEs 
relevant to leaks of MD5 hashes or bad implementations that use MD5 incorrectly, but that's not directly relevant to 
this discussion.

In cases where a product already supports stronger algorithms but somehow "downgrades" to MD5/etc., these are 
reasonable for CVE inclusion because of the violation of an implicit security policy that "the product should use the 
strongest encryption that is available for all interested parties."  This is one reason why downgrade attacks are 
acceptable for CVE inclusion.  Generally, I am personally not in favor of assigning "use of MD5" CVEs to products that 
*only* support MD5 or other weak algorithms.

Putting on my CWE hat for a moment - some leaders in the web application security consulting space have observed that 
lots of public documents give bad security advice and theorized that this may be part of the cause for insecure 
software development.  Near as I can tell (and as reflected in CWE-916: Use of Password Hash With Insufficient 
Computational Effort), it appears that Seth's suggestion to "use PBKDF2, bcrypt, or scrypt" is acceptable "real-world 
developer" advice at this time, although advances in password cracking continue.  (Looking forward to whatever Solar 
has to say on the topic ;-)

We are getting to a point of maturity in vulnerability tracking where once-strong-enough protection mechanisms begin to 
fall out of favor; it is not always clear when something crosses from "questionable practices" to "outright 
vulnerability" and so, there can be a long period in which repositories such as CVE do not have concrete, consistent 
approaches [1].

- Steve

[1] Old-timers may counter "wasn't DES a precedent? How is this different?" to which I say yes, and it's not really 
different to me, but IMO, DES fell out of favor well before the vulnerability-information industry became an "industry" 
and had to deal with long-term shifts in vulnerability and attack knowledge.


> -----Original Message-----
> From: Seth Arnold [mailto:seth.arnold () canonical com]
> Sent: Wednesday, October 09, 2013 2:09 PM
> To: Rich Felker
> Cc: oss-security () lists openwall com
> Subject: Re: [oss-security] Source of bad password hashing practices? MySQL
> manual...
>
> On Tue, Oct 08, 2013 at 07:57:52PM -0400, Rich Felker wrote:
> > It's come to my attention recently that the MySQL reference manual is
> > recommending very poor password hashing practices as part of its
> > security guidelines:
> >
> >   "Do not store cleartext passwords in your database. If your computer
> >   becomes compromised, the intruder can take the full list of
> >   passwords and use them. Instead, use SHA2(), SHA1(), MD5(), or some
> >   other one-way hashing function and store the hash value."
> >
> >   (http://dev.mysql.com/doc/refman/5.7/en/security-guidelines.html)
> >
> > With MySQL being one of the major traditional "LAMP stack" components,
> > I wonder if this is the source from which many web developers are
> > getting their ideas on how to do password hashing. What is the proper
> > procedure for publicizing documentation bugs like this which are
> > leading to poor security practice, and for getting them fixed?
>
> I don't know if we can realistically assign a CVE number to bad advice
> on the Internet :) , but it would be immensely useful if this paragraph
> could be updated to say:
>
>   "Do not store cleartext passwords in your database. If your computer
>   becomes compromised, the intruder can take the full list of
>   passwords and use them. Instead, use PBKDF2, bcrypt, or scrypt to
>   compute unique hash values suitable for storing in the database."
>
> A further change that might be nice would change "If your computer becomes
> compromised ..." to "When your computer becomes compromised ..." but I
> could understand if the MySQL team doesn't share my pessimism and choses
> to ignore this small change.
>
> But please, MySQL team, feel free to use my proposed paragraph under
> whatever license you wish. The old one has to go.
>
> Thanks