php crypt() blowfish salt length backward compatible

Question

I used crypt() to hash password, with a blowfish salt like this:

$2a$, 2 digits, $, 21 chars in [a-zA-Z0-9]

Here I made a mistake that chars length after third $ is 21 not 22. But it worked fine so I didn't find the error.

It works on my desktop which running windows and php 5.4.4 and on AWS ec2 which running Amazon linux with php 5.3.x, with that too short salt.

One day I updated AWS php to 5.5.14. then the problem occurred. crypt() return *0 all the time.

After some try, I added a $ at end of the salt so , it become 22 chars. And it works again and return the same hash string as before. Although it doesn't obey the blowfish rule, chars should be [./a-zA-Z0-9]

But now I duplicate this site to another machine which running openSuSE 13.1 with php 5.5.14, This salt failed again.

I downgrade php to 5.4.20 but not help.

The new site still need old database so I have to make that password hash works.

What is the library or module that effect this blowfish salt length error compatibility issue? Tt seems not PHP's version. AWS 5.5.14

Or is there another magic char can save me again? I tried replace th tail $ to each one in [./a-zA-Z0-9] but no lucky, the hash string is different ....

Answer 1

First i would strongly recommend to use the new functions password_hash() and password_verify() to generate and verify new hashes. Of course this doesn't solve your actual problem with the old hashes, but it may be a good idea to mark them as old, so they can be updated the next time the user logs in.

For this old hashes i would try to verify them, generating a salt with a valid last character 22. The crypt function does actually use only part of the bits of character 22 (126 bits of the salt instead of 128). So groups of the last character 22 will end up in the same hash-value.

See the answer to this question Why does crypt/blowfish generate the same hash...

If you try out all relevant characters [.Oeu] as the character 22, the chance is good that one combination will generate the same result as your invalid salt.

EDIT:

Since the used salt becomes part of the password-hash, you should be able to see what was used as character 22 (the 22th character after the third $).