Server sends client a salt, client hashes the salt and password and sends back to server.
Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).
1) A different salt each time, meaning the server must know your plaintext password to validate, or
2) The same salt every time, in which case the hash is essentially the password since that's all the attacker has to pass to the server next time.
Could that really work? Sounds like it's highly abusable if someone compromises the database and gets a list of all the hashes. Now, they don't even need to use rainbow tables or any brute force to compute the password. They just send the hash to the server and will be logged in.
Yes, if an attacker compromises the database they can send the direct hash.
The point is that a malicious or badly-secured site can't use your password on other websites, because ultimately most people use the same password on many different sites.
The salt-and-hash combo is how email logins worked for decades. The problem with this approach is that what you really want different salts, which requires that the server knows the plain text password.
Server sends client a salt, client hashes the salt and password and sends back to server.
Implement this as a built-in feature of the web browser, and the browser can show a special icon or symbol to mark that the password will be sent hashed (and later show a warning on password fields sent via plaintext).