This question already has an answer here:

I'm working on an authentification system. Now in this system the user logs in and sends a hashed password to the server. Is this enough or do I have to rehash the password again?

So basically is this password => hash => network => hash => database

safer then password => hash => network => database? or is hashing already hashed passwords a waste of time and space?

or should it be password => network => hash => database?

As a bonus a likely future expension is to have users login on a remote server where creditals have to be saved and used in future interactions with the server resulting in something like this?

password => network => database1= > network => database2

does this mean having to has 2 or 3 times?

marked as duplicate by Gilles, Mark, schroeder Aug 13 '15 at 2:46

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


There is no extra security in hashing the password before sending it over to the server, as now this hash would become the password. More important is it to send the password over an encrypted channel (SSL/TLS) to prevent it from being sent in plaintext and being read by others on the network.

To store the password you should hash + salt it, again to prevent the password from being stored in plaintext. If the hashing had been done on client side and you store this hash, it would still be like you stored the password in plaintext, as this hash is now the password.

So always hash (+salt) the password on the server before storing it.


It depends on the type of attack.

If the attack is of man-in-the-middle type, then it won't make sense if you hash it again before it reaches the server, because the first hash was already leaked on its way.
If the attack is on the server side, then it would be better to keep password => hash => network => hash => database, as it would make the process of brute-forcing more time-consuming.
If the attack is on the client itself(for example, some keylogger is installed on the client machine), then all these processes would be a waste.

These days, only hashing the password is not at all reliable. You should look at the process of salting to make it more reliable and secure.


You can use scrypt, bcrypt or PBKDF2 for hashing and salting your passwords before storing them. Password hashing is damage containment attitude. I do not see it useful to rehash twice or more. You can attack a secure hash by the use of a rainbow table, which you can prevent by applying a salt to the hash before storing it. I advice you to read this post (Why are salted hashes more secure for password storage?) for more detailed information if you are interested. I have read about systems using this method and their passwords have been still safe during 20 years even if the users kept the same password over the time.


If the hash is sent in plain text, hashing before sending is the same as nothing; an attacker can simply intercept the hash and send a forged request to the server, granting him access. If you are using some kind of encryption scheme (which you should), then hashing twice is meaningless.

What you should do is the following: every time you send the password to the server you send it protected by a layer of encryption. You can use HTTPS for that purpose. Once the ciphertext reaches the server, it is decrypted and the plaintext password is obtained. This procedure prevents a MitM attack, an attacker intercepting the password and using it for authentication. Then, you want to avoid storing the password in plain text, just in case the database is compromised at some point. For this purpose, you hash the password and store it hashed when required (on registration, for example). To authenticate, just hash the password and compare the resulting digest against the stored hash.

In addition, you can implement hash salts to make the cracking task more difficult for those who manage to get the hashes stored in the database.

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