2
$\begingroup$

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.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ I've updated my original post; all communications will be secured through SSL. $\endgroup$
    – Alex Jeffrey
    Commented Feb 8, 2013 at 13:15
  • 2
    $\begingroup$ Do it the other way round. Bcrypt on the client, and SHA-256 on the server $\endgroup$
    – CodesInChaos
    Commented Feb 8, 2013 at 15:58
  • $\begingroup$ wouldn't that require a consistent hash? I suppose I could use the user's email as a salt. $\endgroup$
    – Alex Jeffrey
    Commented Feb 8, 2013 at 16:03

1 Answer 1

Reset to default
2
$\begingroup$

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?

Improve this answer
$\endgroup$
6
  • $\begingroup$ Hashing before sending is performed to give the user verifiable assurance that we do not know their password, and also to make it more difficult to gain access if a hacker accesses our servers and is able to monitor inbound traffic - they would need to know the PBKDF2 key which is generated from the original password, not the hash. $\endgroup$
    – Alex Jeffrey
    Commented Feb 8, 2013 at 15:46
  • $\begingroup$ I'm also aware of the issues of cryptography in javascript, and intend to implement code-signed source coupled with a browser plugin to verify the signatures at a later date. $\endgroup$
    – Alex Jeffrey
    Commented Feb 8, 2013 at 15:46
  • 1
    $\begingroup$ For many, many real-world passwords, knowing the digest is practically equivalent to knowing the password. Thus, the verifiable assurance that you don't know the password is useless unless users choose good passwords, same for the hacker who monitors inbound traffic. $\endgroup$
    – mikeazo
    Commented Feb 8, 2013 at 15:52
  • $\begingroup$ does SRP solve this problem though? Given the context that this will be a security application, users will be pushed towards choosing a longer passphrase which should resolve this problem. Another possibility is using their email address as a salt to get hash with greater entropy. Is SRP a better solution than these? I'm unfamiliar with it. $\endgroup$
    – Alex Jeffrey
    Commented Feb 8, 2013 at 15:58
  • 1
    $\begingroup$ SRP is pretty cool IMO. From wikipedia: "an eavesdropper or man in the middle cannot obtain enough information to be able to brute force guess a password without further interactions with the parties for each guess. This means that strong security can be obtained using weak passwords. Furthermore the server does not store password-equivalent data. This means that an attacker who steals the server data cannot masquerade as the client unless they first perform a brute force search for the password." $\endgroup$
    – mikeazo
    Commented Feb 8, 2013 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.