A lot of web developers are under the impression that client-side hashing is a valid substitute for sending passwords over a secure SSL-encrypted link (HTTPS).
Some even believe that it is more secure, simply because the user’s password isn’t sent over the network as “plaintext”.
Unfortunately, a lot of this is based on a misunderstanding of why we use password hashes in the first place.
Typically, client-side hashing is used in order to try and prevent man-in-the-middle attacks.
However, to an attacker, it doesn’t really matter if they can see the user’s plaintext password or a SHA1 hash. The attacker only cares about the client is sending to the server.
In other words, what is the server expecting?
If I can sniff out the fact that a client browser is sending “aab0969638e3cd6d63b4b0bba36f8d041dbf1d78” as a password parameter, what’s to stop me from sending the exact same hash? Will your server know the difference?
If you use client-side hashing as a substitute for server-side hashing, then you might as well be storing plaintext passwords.
The attacker doesn’t care if they can see the user’s password or not. The only thing they care about is being able to authenticate with the server.
The worst thing about all of this is that you’ve completely forgone the benefits of using a slow hashing algorithm such as bcrypt, as an attacker could potentially throw a bunch of pre-fabricated hashes at your server.
I think there is something to be said about the dangers of conflating password security with transport security. Protection against eavesdropping is the job of SSL, not hashing.