[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Oct 2013 19:03:07 +0000
From: "Christey, Steven M." <coley@...re.org>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
"Rich Felker" <dalias@...ifal.cx>
Subject: RE: Source of bad password hashing practices? MySQL
manual...
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@...onical.com]
>Sent: Wednesday, October 09, 2013 2:09 PM
>To: Rich Felker
>Cc: oss-security@...ts.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
