Where should I hash user passwords?

Question

The obvious answer is hashing. I'm thinking of using SHA512 to hash a salted password.

My question is this: Where should I hash the password?

I've thought of two ways:

(1) I hash it in the application. That will mean the hash is transmitted to the server. The server then checks it against the stored hash, and logs in the user if the hashes match.

(2) I hash it on the server. The hash is checked in the same way.

My problem is that I feel the password would likely be intercepted. In (1), the hash could be extracted by a man-in-the-middle attack. The attacker can now simply use that hash to get access to the user's information.

In (2), the attacker can intercept the plain-text password, and use that to gain access to the user's account.

Is the solution that I need to hash on both sides? Hash with the salt on the client and then hash again on the server-side?

I am not sure how to proceed. I don't want the user's information to be accessed.

If you can point out the benefits of your suggestion too, I would be thankful.

Answer 1

Just use SSL and pass the password in plain text. Seriously, just use HTTPS.

Hash the password on the server.

If you hashed it on the client, you're susceptible to something known as a "replay attack", where the attacker can intercept a request, steal the "salt + hash" and then use that to authenticate.

In (2), the attacker can intercept the plain-text password, and use that to gain access to the user's account.

If the attacker is capable of MITM attacking SSL, then all is lost anyway. They can do much more damage than just intercepting a password. (and it's far less likely)

However, consider using federated authentication such as OAuth2 or Google+ Sign-in as both handle this for you.

Answer 2

Let's start from the beginning.

1. Salt each password using a cryptographically secure pseudo-random number generator.
2. Hash the combination of salt+pass
3. Transmit BOTH the salt and hash over an encrypted, or private channel
4. Store BOTH the salt and hash in a database, or a text file, or whatever the hell you want (A database has the added bonus of requiring additional authentication, security is layers)
5. When the user enters their pass again (over an encrypted or private channel), you hash it with the same algorithm, using the salt that you stored earlier.
6. If the resulting hash matches, they are authenticated, if not, tell them they got EVERYTHING wrong.

Can the salt be generated server-side (to ensure it's unique) then sent to the client, before the password is salted and hashed?

You should absolutely perform the salting server-side to ensure you have maximum control over this process. Never allow the user, client, or device to make their own salt.

Could the salt and hash be used to gain access to a user's account? Is the encrypted channel meant to prevent any man-in-the-middle attacks?

If somebody gains access to all of the stored hashes and salts, they could try to do a bruteforce/dictionary attack to try to get a matching hash, but they could only ever do them very slowly, since every hash has a different salt.

Keep in mind that if a person has a short or weak password, theirs can still be cracked quickly.

If they all have the same salt, when they crack one, they essentially crack all of them.

The encrypted channel is to prevent people from listening in on the communication between client and server. It does not guarantee that it will stop a MITM attack, but it should add a layer of protection in the fact that the MITM cannot validate themselves as you/your organization.

How do I ensure that the channel between my android app and Google App Engine is secure?

It depends, is it over the web? Use HTTPS and validate your application with an SSL certificate, with Extended Validation if it is in your budget.