Hashing support for bcrypt

[migrator]

Please support bcrypt in com.google.common.hash.Hashing

http://en.wikipedia.org/wiki/Bcrypt

"A Future-Adaptable Password Scheme" by Niels Provos and David Mazieres (USENIX, 1999) http://www.openbsd.org/papers/bcrypt-paper.ps

relevance: 3

[migrator]

summary: Not Defined

No one should be using bcrypt for hash tables, which is what Hashing is for.

status Not Defined creator: tavianator@gmail.com created at: Sep 24, 2014

[migrator]

summary: Not Defined

Hashing is not only (or even primarily) for hash tables: https://code.google.com/p/guava-libraries/wiki/HashingExplained

status Not Defined creator: cgdecker@google.com created at: Sep 24, 2014

[migrator]

summary: Not Defined

Bcrypt is one of the three good password hashing schemes -- md5() or sha256() are outdated and insecure.

https://password-hashing.net

http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage

http://codahale.com/how-to-safely-store-a-password/

status Not Defined creator: sebastia...@gmail.com created at: Sep 24, 2014

[migrator]

summary: Not Defined

sha256() are outdated and insecure.

That's pure nonsense. SHA-256 is still rather modern (SHA-3 is out, but it'll take years) and secure HASH FUNCTION.

bcrypt is NO hash function, it's a key derivation function. Using hash functions as a KDF is insecure, no matter how good the function.

A KDF is no com.google.common.hash.HashFunction as it always needs a salt. This is can be an additional input1 or generated randomly2. Fitting it to the interface by fixing an argument would be a very stupid idea. Allowing a hash function to behave randomly would be no smarter.

I'm not saying that it doesn't belong to Guava, I'm just saying that it doesn't belong to the hash package. No HF is a KDF and vice versa.

status Not Defined creator: Maaarti...@gmail.com created at: Sep 24, 2014