1
votes

Right now we're trying to migrate user password hashes from a basic node.js v0.10.48 application to a Meteor server. I was hoping by using the same version of bcrypt for password hashing would could migrate the hashes themselves, but so far the compare isn't working.

I've made sure that both are using the same version of bcrypt, and each of them works individually to compare hashes they themselves created. But I can't compare a hash created on server A with one created on server B using the same password.

Is there a way to accomplish what I'm looking for?

EDIT: Adding in some examples. First is run on the Meteor side:

The password its hashing here is already a SHA256 hash (and that part lines up just fine between the two servers).

> bcrypt.hashSync(SHA256 HASHED VALUE, 10)
'$2a$10$ky0cB/ezKnyLojOEVfkS9O9jn0V5Lo3BNMLIU2jTokHDcQDk33A0y'
> bcrypt.hashSync(SHA256 HASHED VALUE, 10)
'$2a$10$FdoTohtW/Djd1CN9MJJk6OmD7z60sBUaz56ez62.V/XH7r5s5yBtu'
> bcrypt.compareSync(SHA256 HASHED VALUE, '$2a$10$ky0cB/ezKnyLojOEVfkS9O9jn0V5Lo3BNMLIU2jTokHDcQDk33A0y')
true
> bcrypt.compareSync(SHA256 HASHED VALUE, '$2a$10$FdoTohtW/Djd1CN9MJJk6OmD7z60sBUaz56ez62.V/XH7r5s5yBtu')
true

And on the node application side, using that password I get the same SHA256 hash but then after running bcrypt on it with the same salt (intentionally just using the same value for testing here) I get

$2a$10$ONspBE0StIMRH0GJOI3zO.uFey4yk7dFS85EycN.lnklr4QZk9T0a

Running similar tests as above with the same SHA256 hash gets a false result.

2
How did you make sure that they are exactly the same version? As bcrypt is build using node-gyp on your architecture it will be built new when you hit Meteor npm install against the node version that Meteor runs on. - Jankapunkt
Can you actually confirm that the same password produces 2 different hashes depending of the application? Can you post the code for hashing a password and comparing it? - Florian Burel
What I meant by that is both are using version 0.7.7 of bcrypt (after checking manually), and for the one in my control I cleared / installed it. Would I need to clone one to the other for that portion to work? - Joe
As well as some simple examples of hashed passwords (not real ones obviously) - phuzi
I've add some examples with an edit - Joe

2 Answers

0
votes

There are a couple of things to check with BCrypt.

  1. How many rounds of hashing are being performed, and
  2. Which version of the algorithm is being used.

These should both be easy to check as they should be encoded at the beginning of the stored hash.

A hashed password Password could look something like

$2a$04$b.ATnW5JRfDNyKnKJ8SBO.QwtkLANvAc751Qn.N/wcxZmA/CIDFNK

Where $2a$04$ shows hash version and number of rounds.

See Wikipedia BCrypt Versioning History for more details on algorithm versions.

If the version is the same then it's likely the rounds of hashing are different, both should be configurable.

0
votes

What does that mean, migrate the hashes?

Observe that meteor hashes the password the user inputted client-side:

https://github.com/meteor/meteor/blob/1dbc3304c715ae5bc66efd8e02c7e1e2b86540a2/packages/accounts-password/password_client.js#L77

Is this what you expect?

Were the original user passwords hashed before being fed into bcrypt? If not, you will need to modify accounts-password to login with the password directly and not a client-side hashed password. You would change the above code to do that.

If they were hashed before being fed into bcrypt, observe that Meteor has its own SHA256 package that may differ slightly in output compared to crypt:

https://github.com/meteor/meteor/blob/devel/packages/sha/sha256.js

Don't mess with the salt. It isn't the issue.