Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are very few websites that hash the users password before submitting it to the server. Javascript doesnt even have support for SHA or other algorithms. But I can think of quite a few advantages, so why is this practise so uncommon among websites?

share|improve this question
What advantages do you think there are to client side hashing of passwords? – Tim Lamballais Mar 18 '14 at 10:34
@TimLamballais A typical client can spend far more time on hashing than a server. So if you have a high performance implementation in the client (which rules out javascript in current browsers) you can use more expensive and thus stronger password hashes. It also means that the server never sees the password itself. Client side hashing is also a prerequisite for augmented PAKE protocols like SRP where impersonating the server doesn't give you access to the password. – CodesInChaos Mar 18 '14 at 10:58
Javascript isn't really that slow anymore. Modern javascript engines have become so fast that they are on-par with compiled languages and recent additions like typed arrays provide the proper tools for the number-crunching required for cryptography. – Philipp Mar 18 '14 at 11:57
@TimLamballais One advantage would be that the server never sees my real password, and cannot possibly leak it (yes, they can still leak the hash, but it should be salted by the domainname, so useless for login to other sites). But for the largest advantage see my comment to Phillip's answer. – Muis Mar 18 '14 at 13:43
A lot of people question whether any extra security is gained with this practice. One thing it does do is reduce risk. If you always hash or encrypt (I've seen steam/valve encrypt with a public key and I bet they are not decrypting) there is no chance of you ever having an embarrassing plaintext breech. isn't any more secure but it isn't pointless – Rell3oT Mar 18 '14 at 14:34

To understand this problem, first you have to understand why we hash passwords. It is completely possible to store a password in plain text on a server and simply compare the password transmitted to the password received. As long as the password is protected in transit, this is a secure means of authentication (shared secret).

The reason that passwords are hashed is because the problem isn't the authentication, but the storage. If the server is ever compromised, the attacker would immediately have access to all user accounts as they would now know the secret used for authentication of the users.

Hashing acts as a barrier to this. Since the server doesn't know the actual input required to authenticate, even a compromise to the DB does not grant an attacker access to the user accounts. They would still need to figure out the input to give to reach the hash values the application checks against. Sure they could alter all the values to something they know, but this would rapidly throw up suspicion and the system would be shut down and secured.

So, the problem with client side hashing is that it effectively makes the result of the hash the password rather than the password. There is nothing to stop an attacker from bypassing the official client and simply sending the finished hash to the server directly. It provides no additional (or loss) of security during the authentication, but under the situation that hashing is designed to protect against, it offers nothing since the hash stored in the DB is actually the shared secret transmitted to the server.

That said, there are two notable thing client side hashing does give you. While it doesn't help protect you're system at all, it may help protect your user. If you are insecurely transmitting the password or the transmission get's compromised without the client code getting compromised, you will still protect the user's password (which they may reuse on other sites) from being leaked.

The other is that you can provide additional iterations of a hash to make an offline attack against the DB more difficult without having to use server cycles, but you still need sufficient server cycles to protect against a rogue client. Again, the primary protection this offers is preventing the original password from being discovered but does nothing for helping protect the authentication mechanism of your site.

Put another way, while it does provide some minor protections, from the point of view of the server, the client side hash should be treated as if it was the user's direct password. It provides no more or no less security on the server than if the user had directly given their password and should be protected as such.

If you want to be able to provide that extra level of security, I would recommend two hashes. Hash once client side to build a new, unique password, then hash that password on the server to make a value you store in the DB. This way you get the best of both worlds.

For the most part, SSL is trusted sufficiently to protect the exchange that the initial hash prior to transmission is seen as unnecessary though and a compromised server could always alter the code sent to the client such that the initial hash isn't performed. It simply isn't an effective alternative to SSL and doesn't offer enough additional advantage to be worth the costs and complexity.

share|improve this answer
I need to encrypt some data client-side, and by sending only the hash to the server, I can proof that the server cannot decrypt the local data, since it doesn't know the plain-text password. Also, when salting the hash with the domainname, there is a garantuee that the server can never leak my password, just a salted (useless) hash. – Muis Mar 18 '14 at 13:46
@Muis my point is that the salted hash isn't useless. It can compromise the integrity of your authentication system as it is the new password for authentication (even if not for encryption). The attacker could still get the hash from the DB on the server and convince the server that they are the user and access the encrypted copy of the files (which granted, they may have access to already anyway at that point). Additionally, a salt should be globally unique, not a domain name. – AJ Henderson Mar 18 '14 at 13:49
@Muis - my point is simply that you should treat the hash generated client side as if it was the user's own password when dealing with it server side. It isn't bad to use a client side hash to protect the user's password from being exposed to the server, but it practically acts like the user's direct password as far as the server is concerned. – AJ Henderson Mar 18 '14 at 13:52
My main worry is that the leaked password can be used to login to OTHER sites, where the customer used the same username/password combination. This will be prevented by adding the domainname to the hash (since I cannot store an unique value persistently in javascript). – Muis Mar 18 '14 at 14:10
@muis the salt need not be protected. Store it on the server and send it to the client before hashing. If the server can't be trusted for this, still use the domain name and user name appended to the server supplied data perhaps. – AJ Henderson Mar 18 '14 at 14:12

What advantages would client-sided password hashing have?

Well, the password wouldn't be sent over the net in clear-text. But you should really be using TLS encryption when you log in, so password sniffing should not be an issue.

Another reason could be that you don't want the server to ever be aware of the users password, not even for a microsecond. That means you give the server the password hash on registration and then log in using that password hash. Unfortunately this doesn't solve anything: The shared secret to log into the account is now the hash, not the password. When you obtain knowledge of the hash, you can log in without knowing the actual password (because the server doesn't know it either).

share|improve this answer
The advantage for me would be that I can use the user's password to encrypt some local data in my app, and proof that the server is never able to decrypt that data (since it only knows the hash). Otherwise I would have two prompt the end-user for two different passwords (1 for login, 1 for encryption). – Muis Mar 18 '14 at 13:41
@Muis In that case the answer would be "Because nobody has such exotic requirements like you do". – Philipp Mar 18 '14 at 13:54
@Muis, your definition of "proof" must be weak as often knowledge of the hash is equivalent to knowledge of the password since dictionary attacks are so successful. I do see your point though. It is proof if the user picks a good password. – mikeazo Mar 18 '14 at 15:30
@mikeazo I salt the hash, so dictionary attacks are useless. – Muis Mar 18 '14 at 15:53
@Muis That's not how salting works. Salts only protect against precomputed rainbow tables, not against dictionary attacks. – Philipp Mar 18 '14 at 16:01

Since you are talking about web application...

In a database we have a table call dbo.useracc we are storing these hashes password

User        Password
--------       ----------
user1       5f4dcc3b5aa765d61d8327deb882cf99
user2       202cb962ac59075b964b07152d234b70
user3       098f6bcd4621d373cade4e832627b4f6

and our login function in web application be something like

if (user == $user and password == $pass) {
           return auth.token

Let's say an attacker successfully hacked and stole the database and saved our dbo.useracc data. He now has our hashed password.

If your login hashes process is stored in the client, the attacker can still accesses your account with the hashed password by just hooking up the HTTP POST method altering the password field to send your hashed password and he is still able to login. Remember your application data are communicating with the server through the POST method eventually after it's hashed to be checked against.

However if the hashing process is in the server, it's another story.

$pass = md5.hash($pass);

if (user == $user and password == $pass) {
           return auth.token;

If the hacker use the hashed password to login, it will be a hash 'hashed password' checking against a hashed password.

In this case let's say the attacker post

$user = user1 $pass = 5f4dcc3b5aa765d61d8327deb882cf99

After the server side doing $pass = md5.hash(5f4dcc3b5aa765d61d8327deb882cf99) it will return '696d29e0940a4957748fe3fc9efd22a3' which is returning a false statement.

This is to fence off attacker who has successfully stolen the database data and trying to access through the web application using the hashed password. And of course the attacker still can hack into the accounts if they successfully bruteforce / crack the hashes through dictionary attacks and so. However the hacker requires longer time if the password is a good password after compromising the system and the server admin could just reset the password and email the users.

Also it is also used to internal threats like employees in an enterprise. In an enterprise, there will be Database Administrator and Developers. They are different roles. Now to prevent the employee users to access to the sensitive data, they need to have access to both application and DB to get access to the data. Of course you might argue a DBA can still alter the database data through the database itself, but it is not accessible by the developers and it is easier to pinpoint where is the attack from. It is about access control rights and minimizing the risks and threats.

share|improve this answer
You're correct that it doesnt make it harder for an attacker to enter MY site using the stolen hash, but it makes it harder to login to ANOTHER site, since the other site most likely dont use exactly the same salt + hashing algorithm. – Muis Mar 18 '14 at 14:04
There's no way the attacker can access ANOTHER site with the hashed password too as long as the ANOTHER website don't practice hashing in the client and is a good password that is hard to be bruteforce by dictionary or rainbow table attacks. And as a developer, why would you even care about "ANOTHER" site in the first place. If the users value their other data a lot, they should practice not to use a global password instead. – Sky Mar 18 '14 at 14:11

It is good practice to hash on the client side, then salt the password and hash again on the server side. This is an extra layer of protection against man in the middle attacks. SSL is the first layer however Snowden's revelations made it clear that SSL can be compromised by organisations such as the NSA with relative ease.

share|improve this answer
This answer provides nothing that the other answers don't, and misses the point that to a MitM, the client's hash of the password can be used as if it were the password itself. – Mark May 5 '15 at 8:29
@Mark Um no Mark. This does indeed help with mitm. Mayhem is stating at hashing the hashed password yet again. – Karl Morrison Jan 28 at 22:02
This is a good idea I haven't thought of. Hash on the client side to hide the plain-text password, then hash on the server side to protect from a server-side breach. Thanks for sharing! – Aaron Gillion Apr 15 at 23:55

i think the probability of being hacked in client-side is more higher than that in server-side. (Because there are some IT expert look after the server) . if your computer is already being hacked. the client-side 's algorithms which used for hashing your password also can be stolen by hacker . Aso soon as your algorithms is no longer a secret. i think,it become useless.

share|improve this answer
We generally frown on secret algorithm (See Kerckhoffs's principle and security-through-obscurity. Password hashing certainly doesn't need to rely on this. At most we apply a key and hope that the attacker doesn't find even if they manage to steal the database. – CodesInChaos Mar 18 '14 at 11:03
The "server is more secure" argument makes little sense in this context. 1) The client knows the plaintext password, so a trojan can trivially steal it with a key-logger. 2) Password hashing only offers an advantage over plaintext passwords when the server gets hacked and the database gets stolen. – CodesInChaos Mar 18 '14 at 11:05
danke,CodesinChaos. you offered me a useful lesson for free. – Li Billy Mar 18 '14 at 11:14
The way twitter works is that you follow people whose tweets you find interesting. No need to ask for permission. – CodesInChaos Mar 18 '14 at 11:20
A server with all its user data is a way more valuable target than one single user. – Gumbo Mar 18 '14 at 14:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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