A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.
Ah yes, "if nobody makes any mistake there's no problem", that's worked so well forever hasn't it?
> Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
That makes quite literally no sense, did you miss the entire thing and go off with whatever?
The request here is to make the browser's support for HTTP authentication better. The entire point is that there is no "quick code edit" without owning the entire browser at which point you're quite thoroughly owned anyway.
A compromised website that was well designed should not leak your password any more than a client-side hashing implementation. This is because the passwords are hashed in the database. Client-side hashing means that, yes, initially the website is not receiving plaintext passwords, but a few quick code edits to maybe add some logging JavaScript or disable the client-side hashing implementation will fix that.
And credential stuffing? Client-side hashing does absolutely nothing to prevent credential stuffing other than that you may need a GPU to do a lot of hashes quickly. Client-side hashing doesn't make a server handle more or less authentication requests.