Bcrypt has in interesting limitation, it only uses the first 72 bytes to generate a hash. Anthony Ferrara covers why you may want to live with that limitation: Security Issue: Combining Bcrypt With Other Hash Functions.
The specific example he covers is pre-hashing with the raw output of hash_hmac(), which can contain null bytes:
this means that the output can contain null bytes. In fact, it means that on average 1 out of every 256 passwords (or 0.39%) will have a leading null byte. So we only need to try approximately 177 passwords to get a 50% chance of finding a hash with a leading null byte. And we only need to try approximately 177 users to get a 50% chance of finding a user with a leading null byte. So trying 31329 permutations of users and passwords gives us a 25% chance of finding one that will work.
…
This is bad. This is really bad.
Oh the null byte, you have been the source of many unexpected results.
If you don’t use the raw output of hash_hmac() then you won’t get null bytes and you’ll be fine. By default raw output is set to false.
You are 100% safe if you do one of the following:
- Use straight bcrypt (don’t pre-hash)
- Use hex output from the pre-hash
- Base64 encode the raw output of a pre-hash
If you are using raw output, encode it first, and you’re safe.
There are so many ways to mess up cryptography. This is not the kneecap you want to get shot in. Nearly every situation should stick with existing, widely used and tested, crypto options.