On Wed, Feb 5, 2014 at 3:08 PM, Zachary Harris zacharyharris@hotmail.comwrote:
tl;dr PBKDF2 and bcrypt are both perfectly acceptable for security.
PBKDF2 and bcrypt, as well as scrypt, are all well regarded by current infosec industry standards (with "current" being a key word). " While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions [that have] very little computing overhead" (CWE 916). Feel free to use whichever one best meets the project needs in terms of implementation, user version migration, etc.
Custom crypto algorithms should indeed always be completely off the table, including any (supposed) "minor" custom modifications to crypto standards. Indeed, custom _implementations_ themselves are best to be avoided in favor of established libraries whenever possible.
I had not heard of Whirlpool before. While (based on WP) the algo has a reputable designer, hashes can be built for different purposes, and the WP page does not appear to indicate that this one was designed for the purpose of strengthening the difficulty to crack. Indeed, the phrase "... was changed ... to one which ... is easier to implement in hardware" is an _undesirable_ quality when it comes to the goal of key stretching.
Note that much confusion on the web about key lengths with bcrypt ("72" vs. "56" bytes) comes from the fact that there are TWO algorithms called "bcrypt" which both happen to use Blowfish. One is an encryption algorithm, and the other is a hash algorithm. While they share a common core component, the purposes are thereby entirely different. For the sake of the bcrypt HASHING/key-strengthening algorithm (which we care about now), the 72-byte input parameter is in no way a theoretical problem at all, even for non-Latin UTF-8 based passphrases which eat up 3 bytes per unicode point. The reason is because the text-based passphrase itself needs to "somehow" be converted into 18 words of 32-bits each anyway. (If we were _encrypting_ then the 56 bytes limit for THAT algorithm would come into play.) Even if you restrict your attention to ASCII it would not be ideal to simply convert ASCII code points to a (zero-padded) juxtaposed stream of 32-bit chunks anyway, because, well for one thing, you would be throwing away entropy due to not using the upper 1-bit range in each char, not to mention the range of unavailable non-printable ASCII characters. As noted on WP:bcrypt, "Mapping of password to input is unspecified in the original revision of bcrypt." So, despite the strict no-custom-crypto principle already noted, the "passphrase to bcrypt input" mapping is one place where the standard leaves you to just use practical smarts. Seeking to optimize the entropy range in this stage is almost certainly overkill anyway. Still, I believe we can do better than a "truncation of utf-8 text encoding" rule without great trouble.
Yes, we can hash the password first
References: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet http://cwe.mitre.org/data/definitions/916.html (Use of Password Hash With Insufficient Computational Effort) https://cwe.mitre.org/data/definitions/327.html ( ... Do not develop custom or private cryptographic algorithms) https://bugzilla.wikimedia.org/show_bug.cgi?id=28419 (Re: The Whirlpool recommendation) https://en.wikipedia.org/wiki/Whirlpool_(cryptography) http://en.wikipedia.org/wiki/Bcrypt (Note reference to the "other" bcrypt algorithm near the bottom of External Links)
-Zach Harris, PhD Secure Code Analyst
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l