2

I am using BCRYPT to hash our user's passwords on the database and since the connection from the client might not always be secure, I want to refrain from sending it to the server plain-text upon authentication. We are using Java / Spring's BCRYPT implementation.

  • Is there a way to compare two hashes for the same origin?
  • If no (which probably is the case): what is the best workaround to achieve a similar security level.

Thanks for your suggestions.

Shaun the Sheep
  • 22,353
  • 1
  • 72
  • 100
jvataman
  • 1,357
  • 1
  • 12
  • 13
  • 1
    I don't understand your question and I am probably not alone. – Marko Topolnik Sep 16 '14 at 10:34
  • Possibly answered by http://stackoverflow.com/questions/3715920/about-password-hashing-system-on-client-side ? – Joe Sep 16 '14 at 10:36
  • Thanks Marko, here's an example: - The User's pw is P, it's bcrypt hash is H. With bcrypt H will be different each time it is generated (H1, H2, H3, ...) - The common way to handle authentication would be to generate and store H1 on the server, then the user sends P for authentication. - Since P is used for other purposes and is extremely sensitive I don't want the user to send P for authentication. - The other solution is to have the user send H2 and store P on the server, which is not a good idea either, for obvious reasons. - what I want to do is have the user send H2 and compare to H1 – jvataman Sep 16 '14 at 15:18
  • 1
    You can't, and there is no gain in security by sending hashed passwords (see the link that Joe posted). Hashing passwords on the server side has nothing to do with securing passwords in transit. The bottom line is that you should use an HTTPS/SSL connection for all interactions where a subset of those interactions require passing secure data (such as passwords). – Shaun the Sheep Sep 16 '14 at 16:31

2 Answers2

1

You can't.

BCrypt is a one way function. You can run bcrypt("password") twice and both times you will get different results, and there is no way of knowing that the two hashes are for the same password.

This is a security feature, not a bug.

Instead of attempting this approach, instead you should focus on securing the communication channel by implementing SSL and possibly HSTS.

nostromo
  • 1,435
  • 2
  • 17
  • 23
0

You'll need to set up Public/Private key encryption via RSA, like is used in SSL. The concept is as such: the server has a public key which any client can request. The client uses that public key to encrypt information before sending it to the server. The server uses its private key to decrypt the information (and then re-encrypt it with your bcrypt hash function).

RSA is designed to facilitate this paradigm: information can be freely encrypted with a public key, but the public key is incapable of decryption. Only the private key can be used for decryption.

It's also probably a good idea to salt with a timestamp before encrypting on client-side for increased entropy.

Woodrow Barlow
  • 8,477
  • 3
  • 48
  • 86