They can be transmitted encrypted over https and still readable by the server. It doesn’t make a ton of difference if you encrypt client side, whatever the client sends is “the password”, encrypted or not.
Look at it from the state's perspective: You have nearly unlimited control over your population, but you still can't read their minds. Given how common password reuse is, why wouldn't you track everyone's passwords in case you want access to data stored on systems that aren't already integrated into your sweeping surveillance system?
In the mediocre, they are sent to a server-side app and hashed without being analyzed, and stored in their hashed/salted state.
No good service analyzes your password server side, much less for the offensive nature of your password.
edit: Okay, I suppose there can be some analysis of password strength server-side before hashing at rest. Still, it should not be analyzed for the social acceptance of its content.
They might also want to check it against a list of most used passwords.
What does this protect against?
- The actual password being known to an attacker who can read everything but the client-side state.
- The password has a high chance of being used at other sites as well, so preventing attackers from knowing the password on this site, also prevents them from using it to attack other sites.
But:
- It does not protect against determination to get an authorization token, which is the client-side hashed password that the server sees.
- It does not protect against an attacker who can modify the code which the client receives and runs.
If the password 'Superman' is stored as text in this configuration file I need to fix for a user, there's a good chance I inadvertently learn their password is "Superman" and I may remembers this for hours or days even though I did not set out to learn it. Maybe I half-forget and think it was Spiderman or something, and this wouldn't happen if it was 16 alphanumerics chosen at random, but it isn't.
Whereas suppose the file obfuscates that password with Base64 and stores U3VwZXJtYW4= my brain doesn't see that and realise "Huh the user's password is Superman" or even "The user's password is U3VwZXJtYW4=" it just goes "Some gibberish not important to the current problem" and an hour later I couldn't tell you what it was.
There are a bunch of things we do not because they stop malevolent people from doing evil, but because they avoid tempting good people to be naughty.
[1] https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
So that string is valid only once.
If the hash in the backend is the only thing you need to calculate the salt challenge, then it is the equivalent of a plaintext password. Someone with access to dumps of a compromised backend database can use the hash directly.