The risks of using sha512 in combination with bcrypt

[ghost]

From: Is it good practice to SHA512 passwords prior to passing them to bcrypt?

[...] In particular, many bcrypt implementations expect a password, i.e. a sequence of characters, terminating with the first byte of value 0x00. The output of SHA-512 is binary and thus may contain some bytes of value 0x00. For instance, 1/256th of all passwords will yield a hash value which begins with a byte of value 0x00, that a string-based bcrypt instance will understand as equivalent to an empty password. This is not good...

The solution is to use a deterministic bytes-to-characters encoding, e.g. Base64. Since this implies some size extension, SHA-512 will no longer be adequate (Base64 turns 64 bytes into 88 characters, more than the 72 limit of bcrypt). Therefore, use SHA-256: the 256-bit output (32 bytes) will be encoded by Base64 into 44 characters, and that will be fine with bcrypt.

(The 512-bit output size of SHA-512 is utter overkill anyway. SHA-256 is good enough.)

[niwinz]

Thanks for the notice. And you are completely right that sha512 is not a good approach due to "truncation". After research a litle bit, I found that is not big problem for current users (http://crypto.stackexchange.com/questions/9435/is-truncating-a-sha512-hash-to-the-first-160-bits-as-secure-as-using-sha1); the hash truncation is safe enough for the purpose we are uusing it here.

In any case, I will deprecate that hasher and setup an other combination of bcrypt with proper hasher.

Thanks again.

[niwinz]

Is not fixed in master. The bcrypt+sha384 that does not reaches the 72 limit of chars of bcrypt. This is new default hasher and bcrypt+sha512 is not deprecated and marked to be updateable always.

[niwinz]

Finally, a different solution is taken for it conserving bcrypt+sha512 as recommeded hasher, just fixing it and maintain the backward compatibility for old passwords.