If you want to hop into a rabbit hole, try taking look in Steam's login send the user and pass))

If TLS break then all is untrusted anyway! If you read hash as MITM you can replay it as pass equivalent and log in with hash, do not need knowledge of the original pass. You can just inject the script to exfilatrate original pass before hashing. CSP is broken, since you can edit header to give your own script a inline nonce. I think everything is reliant on TLS in end.

I think 10yr ago before TLS was 99%+ standard on all sites many people would come up with schemes, forums would md5 pass client side and send md5, all sorts were common. But now trust is in TLS.

> Salted hash for transmitting passwords is a good technique. This ensures that the password can not be stolen even if the SSL key is broken

I'm a little confused with this recommendation

How server is supposed to verify user's password in this case? Store the same hash with exactly the same salt in the database, effectively making the transmitted salted hash a cleartext password?

Yes, the server should never have the cleartext password. In this case the salted hash is the same as a password to you, but it protects users who reuse the same password across different sites. If your entire password DB gets leaked, the attacker would be able to login to your site as your users, but they wouldn't be able to login as those users to other sites without brute forcing all the hashes.

Edit: I guess the reverse is also true, that is, leaked user passwords from other sources can't be easily tested against your user accounts just by sending a bunch of HTTP requests to your server. The attacker would have to at least run the passwords through your particular salted hash scheme first (which they can get by reverse engineering your client, but it's extra labor and computation).

That page seems to be a community wiki, and I think the original authors are somewhat confused on that point.

If you salt and hash the password on the client side, how is the server going to verify the password. Everything I can think of either requires the server to store the plaintext password (bad) or basically makes the hashed bytes become the plaintext password (pointless).

There are password-based solutions that work like this --- PAKEs like Secure Remote Passwords: https://www.ietf.org/rfc/rfc2945.txt

They have low uptake because they don't really offer any security beyond just sending the plaintext password over a properly-functioning TLS channel.

Good catch on the wiki authors.

But I think the point of salting + hashing the password isn't quite the same as what TLS offers. It's not necessarily to prevent MITM eavesdropping, but to help protect the user from credential re-use from leaks.

What was I taught is that your server should never have the user's cleartext password to begin with, only the salted hash. As soon as they set it, the server only ever gets (and saves) the salted hash. That way, in the worst case scenario (data leak or rogue employee), at most your users would only have their accounts with you compromised. The salted hashes are useless anywhere else (barring quantum decryption). To you they're password equivalents, but they turn the user's weak reused password (that they may be using for banking, taxes, etc.) into a strong salted hash that's useless anywhere else.

That's the benefit of doing it serverside, at least.

Doing it clientside, too, means that the password itself is also never sent over the wire, just the salted hash (which is all the server needs, anyway), limiting the collateral damage if it IS intercepted in transit. But with widespread HTTPS, that's probably not a huge concern. I do think it can help prevent accidental leaks, like if your auth endpoint was accidentally misconfigured and caching or logging requests with cleartext passwords... again, just to protect the user from leaks.

It doesn’t actually do anything because if SSL is compromised then all of the junk you think you are telling the client to do to the password is via JavaScript that is also compromised.

If you’re worried about passive listeners with ssl private keys, perfect forward secrecy at the crypto layer solved that a long time ago.

For browsers at least, sending passwords plainly over a tls session is as good as it gets.

It's not to protect against MITM but against credential reuse. It offers no additional security over SSL but what it does protect against is user passwords being leaked and attackers being able to reuse that same password across the user's other online accounts (banks, etc.).

That's exactly the case with HTTP credentials and most authentication frameworks...