[XorNot]

Imagine for a moment that instead of all the time wasted on this, we just implemented a protocol amongst the browser makers which allowed a secure password prompt to be requested, and required strong-hashing before sending anything over the wire?

Which would be easier to use and more effective.

[doodlesdev]

If you hash before sending anything over the wire then the hash of your password is now your password, meaning that if it leaks it amounts to basically the same as your password leaking. Granted, applications may choose different hashing algorithms, provide their own clientside salts, etc. which would be really nice. To be fair, I believe more systems should be doing this nowadays, it's really weird to have to send your actual password to the website if a hash would suffice. Then the website could store the salted hash of the salted hash of your password in their database.

Programs such as Bitwarden already do this, where you send the hash of your password to the server instead of the password itself, because from the password you derive the decryption key and you never want that reaching the server. You then use that hashed password as the authorization password, but the client uses the actual password to decrypt the delivered password vault.

[XorNot]

If a common browser protocol required the password to be salted with an application supplied value and then rehashed with the domain name it's served on, there'd be no way to phish a password.

The value the user's browser sends back can't be reversed, so any website prompting from the wrong domain would only ever see an incorrect hash, rather then the cleartext as it does now.