Hello,

This is a followup on the overlong password strategy, but this time with the hash one.

I read this article about using bcrypt for password hashing.

It suggests to pass the password through SHA384 before using bcrypt in order to circumvent the bcrypt limitation.

Your API support this approach, albeit with a SHA512.

However, looking at the code, I couldn't find any mention of base64 encoding after the hash and prior bcrypt.

base64 is suggested in the article because:

Bcrypt truncates on NUL bytes.

And

There is a nontrivial chance that one of the raw bytes in the hash will be 0x00. The sooner this byte appears in the string, the cost of finding a collision becomes exponentially cheaper.
For example, both 1]W and @1$ produce a SHA-256 hash output that begins with ab00.

And

A base64-encoded hash is guaranteed to not contain NUL bytes

Here are some other implementations seen elsewhere:

• In bcrypt.net, they do base64 after SHA256, SHA384 or SHA512. Note the legacy hash without base64, as I was the one opening a similar issue on the repo
• In PasswordLock PHP library, they effectively perform base64 after sha384.
• In passlib Python library, they also perform base64 after sha256.

So my suggestion are:

• Offer other hash (SHA256 and SHA384) to have better interoperability
• Do the same as BCrypt.Net, move the current SHA512 long password strategy as legacy, and implements base64 after hash (and before bcrypt)
  Note that this should be a breaking change, so user would have to choose which strategy to use (and why it can be problematic to continue with the old one)

Thanks.