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.
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
