Who is sending passwords in cleartext on the wire?
Furthermore, pre-hashing doesn't necessarily make transmitting confidential information safer, as one would argue that your client side javascript can be reverse-engineered and give the attacker more information about how you hash your data.
pre-hashing doesn't prevent an attacker from stealing your account if it can read the communication, but it prevents it from having your password and using it everywhere else where you might re-use the password or a permutation of it
Ideally, if TLS was being MITMed somehow such as a dodgy root cert. It would shield the users plaintext password so it could not be used to login into other services. The problem is as soon there is TLS issue an attacker can modify the Js to just send the password in the clear. It really would require code that can't be modified by attacker. This means that there would have to be some sort of browser support. Otherwise it does nothing against the attack it would protect against.
The main benefit is offloading some computation workload on the clients machine. This could allow you to increase the work load required to brute force the password hashes assuming your database leaks. (aka increase iterations or memory requirements)
You last argument is security through obscurity if exposing how you hash makes it easier to brute force the passwords your password hashing sucks.
Hashing the password before sending it doesn't really help you much - the naïve approach is vulnerable to "pass-the-hash" (where you basically send the hash instead of the password as the authentication token). The secure approach involves either some kind of challenge-response or a nonce salt, but these aren't as easy to implement correctly.
TLDR don't do that, send passwords over SSL and use a good password hashing algorithm on the server like BCrypt.
None of bcrypt, scrypt, or Argon2 use them and are not materially worse for it.
[1]: https://sudo.pagerduty.com/for_engineers/
[2]: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
Your password _is_ whatever you send over the wire. Doing a hash in JavaScript before sending it won't obscure the user's password from anyone who can see their traffic; it will obscure the user's password from the user.
Why would you want to see actual user password if you can just not see it?
If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.
E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.
Take a look here: https://arstechnica.com/information-technology/2018/05/twitt....
Of course, a hash that you will receive from client should be treated as a normal password including all good practices.
So, there are properties that differentiate "password" and "5f4dcc3b5aa765d61d8327deb882cf99", even if for the server it's all the same.
And if you don't trust HTTPS to protect sensitive information, why would you send the auth cookies over it that have virtually as much power the password that was given in exchange for them in the first place?
There is no reason you can't also salt on the client. Salts do not need to be secret. The substantial constraint you outlined in your comment isn't a problem.
If you see a password you can leak it by screwing up in numbers of ways. If you never see a password you just can't leak it.
E.g. Twitter recently discovered that they were storing passwords in plaintext in logs, GitHub had similar issue.
Take a look here: https://arstechnica.com/information-technology/2018/05/twitt...
Of course, a hash that you will recive from client should be treated as a normal password including all good practices.
So, not cleartext over the wire then.