This question already has an answer here:
- Client side password hashing 7 answers
Show security to concerned users, that their passwords are at least once hashed(by looking at the JS code), meaning their passwords are somewhat safe in any case.
In the case of a stolen private key, decrypted captured communications between clients and servers would only reveal a hashed password. This would provide access to the corrupted service, but since the password is already hashed(and seeded with the site name or whatever) it can not be used to enter any other websites with email+password unless the hash is broken.
In the case of stealing the password database, the server side hash AND the client side hash would have to be "reversed" to reveal the true password.
Now I am aware that these 3 cases are somewhat rare, however they are not far-fetched imho, since password databases get stolen, private keys are leaked and hash algorithms become outdated(see SHAttered). Now I know argument 3 isn't particularly strong, since passwords are hashed many times over anyway, but nevertheless my question:
Why isn't this best practice? Am I overseeing any drawbacks? Is this already implemented somewhere?