Hash client side. Send hash.

This is how it is done for 20 years (by those who truly care about the users).

If this is so common, it should be easy for you to provide a link to the javascript password hasher on a site you use. Does this site do that? Pretty sure it doesn't. But you sound very confident about this, so I'm sure you'll have no trouble finding some other site that handles its passwords this way.

What?! No!!!

As many have said before, transmitting the hash simply turns the hash into the password itself. Anyone who has your hash, has your password.

The biggest reason for hashing is that, even if an attacker gets access to the hashed passwords, they still can't use them to log in. Client-side hashing completely and utterly undoes that benefit.

Passwords in transit should be protected by SSL. Not a hash.

You should check out SCRAM. It solves this problem without sending the hash or the plain text.

Fascinating. Yes that does solve the problem, and most importantly doesn't send the hash (unlike what the commenter I was responding to was suggesting, which continues to horrify me).

Most interestingly, it solves the problem where the server may not be trusted. I see how this would have protected against the Facebook problem.

I'm curious, have any major websites you're aware of adopted SCRAM as a best security practice? It feels kind of like overkill, since generally the server is considered to be trusted... but at the same time, it would definitely prevent accidental logging.

I have not heard of any website using SCRAM, but recent versions of PostgreSQL use it for password authentication.