I would not only hash it already on the client side, but have it also encoded with a freshly generated one-time-use public key on the client side every time it is being transmitted to my servers.
There are however real schemes to avoid transmitting passwords that may interest you, like PAKEs: https://en.wikipedia.org/wiki/Password-authenticated_key_agr.... But there are still compelling reasons not to use these, e.g. https://palant.info/2018/10/25/should-your-next-web-based-lo....
1. Hashing client-side in addition to standard server-side handling (Have I Been Pwned passwords disallowed, good hash function, preferably memory-hard, salted, peppered for storage, etc.). In this case client-side hashing adds complexity but doesn't improve the security model at all, so we shouldn't do it. Which is why nobody does it.
2. Hashing client-side instead of standard server-side handling. In this case client-side hashing completely breaks the security model, since the hash is equivalent to a cleartext password, so we shouldn't do it. Besides random websites, this kind of mistake has actually been made at scale. See https://en.wikipedia.org/wiki/Pass_the_hash.
In summary, basic client-side hashing either doesn't improve security or compromises it, and is therefore best avoided.
No, this feature is basically Okta working as a password-manager for systems not supporting oauth-flows / single-sign-on. Of course they then need to store and forward the actual passwords to log you in.
And has been for two decades. I was just a high-school kid with a website in ~2001 and I knew plaintext was bad even then.
I did it anyway, but it was just some homebrew blog I built.
How does hashing on the client side help?