Client-side hashing/salting over HTTPS

Question

I'm wondering what the serious issues are with the following setup:

Username/password login scheme Javascript/ajax requests the salt value from the server (we have established in previous questions salt is not a secret value) Javascript preforms an SHA1 (or otherwise) of the password and salt. Javascript/ajax return the hash to the server The server applies another salt/hash on-top of the the one sent via ajax.

Transactions are over HTTPS.

I'm concerned about problems that may exist but can't convince myself that this is that bad of a setup. Assume that all users need javascript enabled as jQuery is heavily used on the site. It's basically attempting to add an additional layer of security to the plain-text of a password.

Answer 1

This doesn't add any additional security. The JavaScript code is present in the client, so the hashing algorithm is known. You gain nothing from doing a client-side hash in this case.

Also, there's no reason why the client should know about the hashing salt. It actually should be a secret value, especially if you're using a shared salt.

Answer 2

You're not gaining anything. There's no point to a salt if Joe Public can see it by clicking View > Source, and the old maxim about never trusting client input goes double for password hashing.

If you really want to increase security, use a SHA-2 based hash (SHA-224/256/384/512), as SHA-1 has potential vulnerabilities. NIST no longer recommends SHA-1 for applications that are vulnerable to collision attacks (like password hashes).

Answer 3

All that effort of passing salts and hashes between the client and server is already built into the underlying HTTPS/SSL protocol. I would be very surprised if a security layer in javascript is going to help very much. I recommend keeping it simple and use plaintext over SSL on the client-side. Worry about encryption on the server-side.

Answer 4

As always: be very careful about designing cryptographic protocols yourself.

But that being said, I can see the advantage in the scheme. It will protect against the password being revealed through a man-in-the-middle-attack and it will ensure that the server never sees the actual password, thus preventing some inside attacks. On the other hand it does not protect against man-in-the-browser, fishing etc.

You might want to read through RFC 2617 about HTTP Digest access authentication. That scheme is similar to what you propose.