[juloo]

The server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example).

I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)

[nitrogen]

There are formalized approaches to keeping the server from knowing the password at any time: https://en.m.wikipedia.org/wiki/Password-authenticated_key_a...

SRP is one such system: https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...

[staticassertion]

The various ZKP approaches are considerably more complex to implement properly vs the trivial approach of a client side hash. There are obvious tradeoffs, of course, but I wouldn't fault someone for an additional hash step on the client.

[Mogzol]

Hashing on the client still seems redundant though. In the end, whatever value is sent to the server is essentially plaintext, because it's all an attacker needs to know to authenticate. Whether it's the raw text the user typed or some transformed version of it isn't really relevant.

[naniwaduni]

In a world where password reuse is rampant, whether it's the raw text the user typed or a hard-to-reverse transformation on it is absolutely relevant to the user, just not to the service provider.