2

I'm trying to implement a cryptographically secured storage site (not Mega, or anything similar) and am trying to prevent the user's password from ever touching the server. The password is used to both log in and generate a PBKDF2 key for AES in Javascript, so the plaintext password should never leave the client machine.

What I'm thinking of doing is getting the client to generate a SHA256 hash of the password and send it to the server, which will then use bcrypt on that hash to create final hash to be stored on the server. My concern is that after hashing the user's password client-side and server-side with two different algorithms, I might either a) be losing entropy in the password or b) opening myself up to attacks due to the mixed hashing methods. Are my concerns based in reality?

Thanks

[edit] all communication will be secured over 2048bit SSL so MITM or sniffing are not a primary concern.

Alex Jeffrey
  • 173
  • 1
  • 6

1 Answers1

2

A problem with your proposed solution is that the digest of the password is now "password equivalent". So, what does hashing it before sending it gain you?

That said, I don't think either of your concerns are concerning (or should be concerning). For the first, see this. If anything, most passwords will have less than 256 bits of entropy anyways. For mixing hashes, see this and this.

A better solution would be to use SRP for which a javascript version already exists.

That said, you are aware of the problems with doing crypto in javascript, right?

Community
  • 1
mikeazo
  • 39,117
  • 9
  • 118
  • 183