Interesting, that page links to two problems that can appear: - bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you

Interesting, that page links to two problems that can appear: - bcrypt implementations that assume zero-terminated strings, which leads to easy attacks if you feed them raw hashes (1/256 chance that the first byte is 0, so on average every 256th user has a password that has a hash collision with with one in every 256 passwords) - password shucking, which is where the attacker has hash(password) from other breaches (where hash is sha256 or similar), and you use bcrypt(hash(password)) (with the same hash function), which allows the attacker to bcrypt the hashes he has, compare them, and if any match can attack the much weaker hash(password). Which is probably why their version uses `bcrypt(base64(hmac-sha256(data:$password, key:$pepper)), $salt, $cost)`. That seems complicated, bu the base64 encoding avoids the first issue, and the pepper the second. I guess that shows how easy it is to get these things wrong, even if it seems trivial.