Disputing advice to SHA256 password before sending to server

[ernsheong]

First up, thanks for this. I was looking for a concrete example, and here it is!

Password is SHA256 hashed on the client before being sent to the server (never simply rely on https and send plaintext passwords over the wire!!)

I would argue that this makes little difference to password security. If we can't trust HTTPS, say an attacked managed to sniff on our hash, the attacker would then simply continue to use that hash to authenticate with the server. There is no benefit to gain from the client hashing the password.

https://stackoverflow.com/questions/1380168/does-it-make-security-sense-to-hash-password-on-client-end

[adam-hanna]

Very true.

The only benefit of client side hashing that I can think of is that clients often re-use passwords on multiple sites. If a server was ever compromised, the client's plain text password might also be compromised. A hacker then might try to login to the client's facebook or bank account.

Now, if everyone did client side hashing without salt, it would be a moot point.

[ernsheong]

In this case if we use bcrypt for password hashing, then even if the server is compromised the user's password is still secure because of the bcrypt hashing with a random salt. I suppose your point is in the case of a MITM attack, your user's plaintext password is protected. But then again with a SHA256 it is possible to work backward with a rainbow table of sorts. It just makes everyone's lives harder: both the hacker and the developer. Cheers.