Revisiting: Pre-hash password before applying bcrypt to avoid restricting password length
Okta released a security advisory 4 days ago, stating that accounts with username longer than 52 characters can login with arbitrary password under specific conditions.
Some people in X/Twitter suspect that Okta use userid + username + password as the input of bcrypt.
If this is true, then the password would be ignored by bcrypt given a long enough userid + username.
A commenter suggested pre-hashing the input with SHA256 before applying bcrypt, thus avoiding the length limit problem. This pre-hash method is also mentioned (and generally approved) in some answers in this site (1,2).
However, the OWASP cheatsheet explicitly discourage this:
An alternative approach is to pre-hash the user-supplied password with a fast algorithm such as SHA-256, and then to hash the resulting hash with bcrypt (i.e.,
bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)). This is a dangerous (but common) practice that should be avoided due to password shucking and other issues when combining bcrypt with other hash functions.
I am not a security expert, so I am looking for professional opinions:
- Should I strictly avoid pre-hashing bcrypt input with another hash function, as mentioned in the OWASP cheatsheet?
- Would I be in serious trouble (e.g. passwords easily cracked) if I pre-hash bcrypt input with SHA256?
- Someone on Reddit suggest that salting the sha256 hash BEFORE applying bcrypt can prevent password shucking. Is this true?
