This question already has an answer here:
I've been investigating various protocols used to send usernames and passwords to web servers in order to authenticate, and while obviously all of them these days use SSL/TLS, I was a bit surprised to see that even with my online banking sites the passwords are literally included "as is" in the form body with no attempt to hash or otherwise protect them. Meaning that if either a) somebody has compromised my machine, installing new TLS root authority certificates and causing requests to my online bank to be sent to another server or b) has managed to direct me to a site looking so convincingly like my online banking site that I don't notice it's not (e.g. IDN homograph attack), they can readily capture my online banking password. I could even include c) a malicious operator with access to the backend servers would likewise be able to obtain my password.
The now-popular OAuth 2.0 protocol likewise includes the password unhashed or unprotected as a form field or query parameter (query parameter's arguably even worse as it's not uncommon for query strings to be logged in full by web servers). Given there are well-known and establish protocols for hashing and protecting passwords (e.g. Digest Authentication) that would seem to be provide some obvious benefits in keeping passwords protected, why does it seem to be that nobody is using them?
Even performing a basic SHA256 on the password + pre-determined salt (on the client side) would be better than nothing - obviously if the hash is compromised, an attacker could still use it to access protected services, but at least they don't have any information about my password that could be useful to determine my other passwords, including whatever password I replace the current one with when I'm required to change it (we all know what the most common routine is there!)
The only rationale I can see for passing passwords unprotected (other than over TLS) is that it allows backends to perform complexity validation on them. But even then, that password only needs to be passed once when you first establish it, not for every time you log in (further, the backend could just perform checks against just the hash - e.g. checking against well-known hashes, previously used ones etc., and leave the rest to the client-side, accepting that client-side validations can be bypassed, and it does concern me that even length validation is not something you can do with just the hash).