Does it make security sense to hash password on client end

Question

If you were to hash a user's password prior to sending it across the line and leaving it in plain-text in memory, would this improve the security of the application?

I would assume this mitigates a small fraction of vulnerabilities by protecting the data stored in the clients memory. But really if we're worried about someone reading the client's memory there are probably bigger problems that we can't address.

There's something that doesn't feel right about hashing on the client's end.

Is password hashing on the client end a common practice? Are there any other advantages or disadvantages to doing it?

EDIT: Given the communication channel is secure (SSL). Under what conditions would it be acceptable and worthwhile to use such an approach. I'm asking this because it was suggested by a "security professional" that I use such a scheme during some application functions.

Answer 1

Just make sure that you are sending your password through a secure channel (SSL). If the client can have an application private memory read, then most likely they have bigger problems, like for example a keylogger.

Answer 2

The hash is identical to the password from a security POV in the scenario you describe: if I intercept the hash, I don't need to know the password, I can just send the server the hash I intercepted.

Authentication protocols go to some length to avoid this problem; security is hard, and you are best off selecting and implementing a well-understood protocol rather than rolling your own.

If your traffic is going over SSL, you're safe from interception and hashing gives you little extra benefit.

Answer 3

No.

When the client sends something, whether it is P or H(P) or H(H(P)) anyone who intercepts this can simply resend the exact same thing, thus making any function like this equivalent to using the password directly.

That's why you should use a nonce; The server can give out some random garbage k and the client will calculate H(P,k) and send it to the server. HMAC is a popular implementation of this method.

Provided the server never accepts the same nonce twice, this is secure against a replay attack.

Answer 4

Sending a hashed password won't improve security on your site, as others have pointed out (since you accept a hashed password, all the bad guy needs to know is the hashed version). It's also not really secure, since the bad guy can presumably load your login page and examine the Javascript or Java deployed.

What it does do is prevents somebody watching the packets from being able to pull out a password, and that is moderately useful. Many people use the same password on multiple sites (I do it for all but the higher security sites), and therefore if you can get one password from them you can log into other accounts on other sites.

It also prevents the real password from being stored, even temporarily, on your site, and that may provide a little extra security if your site is compromised.

So, while I'd consider user-side hashing to be potentially a good things, it isn't worth going to much extra trouble.

And, as others have told you, don't roll your own security. There's far too many things that can go wrong. You won't notice them nearly as fast as a practiced bad guy will.

Answer 5

You'd be much better off if you used the Secure Remote Password protocol (SRP). It was designed for this.

Answer 6

No, hashing does not protect the password 'completely'. I'll define 'completely' - passwords can be compromised before they are hashed, or before they are encrypted and sent over the wire. In order to protect any password, a certain amount of protection at the client is also required.

If you want a more concrete example, on why a thorough defense-in-depth protection is required, look no further than the Sinowal trojan. The analysis of the trojan is also available, although that does not provide details on the business damage that Sinowal has wrought. Sinowal (aka Torpig aka Mebroot) is a classic example of why SSL alone is not enough for securing passwords - the password is compromised even before it hits the wire. If anyone even thought of hashing the password, the password would still be compromised before it is hashed.

A defense-in-depth countermeasure would involve (but not restricted to):

1. Client security. An up to date anti-virus scanner, an anti-spyware toolkit, a firewall, and a patched OS is a standard requirement in most operating environments.
2. Multi-factor authentication. The higher the value of the app, the better it is to have multi-factor authentication.
3. Avoid usage of passwords themselves if possible. Use hardware tokens, client certificates for high value apps*.
4. Usage of quality passwords. When you are stuck with passwords as the only option for authentication, it is not enough for the application to protect passwords. Users are the weakest link in the chain and education is sometimes the only way to ensure that they choose high-quality passwords.
5. Choice of the hash algorithm. Everyone knows that MD5 and RC4 are weak. And everyone also knows that snake-oil cryptography is bad.
6. Protect the password throughout all the layers in the application. Apparently, it is not enough to encrypt the password during transmission. One should immediately hash it, and Bzzzzt... destroy the cleartext value. When encrypting the password, choose a good algorithm. If SSL/TLS was used to encrypt the password during storage, use only SSLv3 or TLSv1 (or higher).

*High value apps - Compromise of such an application often results in bankruptcy.

Answer 7

Hashing on the client side opens up another huge hole: you may expose the hashing algorithm. You don't say whether this is web-based (client=JavaScript) or thick-client, but you're giving them more information. Given the channel is secure, you don't have to worry about the clear text password being sniffed.

Besides, if your hashing algorithm requires a salt, you would be exposing your salt, which means if they ever got access to the database, they would be able to decrypt every password.