Is it possible to migrate from bcrypt to crypto?

Question

Having multiple ACL with user records and password generated with.

bcrypt.hashSync(request.password, bcrypt.genSaltSync(8))

We can compareSync these passwords without the need to generate the salt using the compareSync() method.

bcrypt.compareSync(request.password, ACL.password)

I understand that bcrypt hashes contain the salt, hence the compareSync method does not require the sale to compare a hash with a password [string].

Using crypt to generate a salt and hash the password I can neither compare the hashes generated from pbkdf2Sync with scryptSync methods, nor with the bcrypt hash.

let cryptoSalt = crypto.randomBytes(8).toString('base64')

let pbkdf2Hash = crypto.pbkdf2Sync(request.password, cryptoSalt, 1000, 44, 'sha512').toString('base64')

let scryptHash = crypto.scryptSync(request.password, cryptoSalt, 44).toString('base64')

Is there any way to use crypto to generate a hash that can be compared to a hash generated with bcrypt?

Should it be possible to create the same [base64] hash from pbkdf2Sync and scryptSync using the same salt?

Answer 1

bcrypt, PBKDF2, and scrypt are all password hashes, but they all work differently and hashes from one format cannot be converted into another. This is because they're all effectively one-way hashes that work differently internally.

Also, in general, you should avoid PBKDF2 unless you need FIPS compliance. The reason is that scrypt and Argon2 are memory-hard hashes, which means that they use a certain amount of memory to make them harder to crack on GPUs, which is good. bcrypt also happens, just coincidentally, to be rather difficult to crack on GPUs. PBKDF2 is greatly sped up on GPUs, which is bad, so it should be avoided.

You can set up code to handle a migration between the two, however. First, make sure your bcrypt hashes all use some fixed prefix. Often this is something like $2b$, but whatever you do, make sure it's unique.

Then, when someone logs in, if the hash uses bcrypt, verify the password, then re-hash it with scrypt (or Argon2 or whatever), which should also have a unique prefix, and write the new hash to the database over the old one. If the user already has an scrypt hash, then there's nothing to do.

Now, unless you force all users to log in every so often, some users will continue to use the older bcrypt, and you'll just have to accept that. Most users will, however, be updated in time, which improves security.