- Accidentally recognisable passwords in logfiles, tracefiles, network dumps, HTTP request traces, HTTP proxy coredumps.

- 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.

So instead of the attackers/admins seeing your password, they see a string of characters that, when delivered to the server along with your account id, grants access to your account. Hm.

It's a similar value to obfuscation schemes.

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.

The best systems aren't vulnerable to that, since it's a 2-way handshake using a Password Authenticated Key Exchange (PAKE)[1] like SRP (Secure Remote Password) or OPAQUE[2].

[1] https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

[2] https://eprint.iacr.org/2018/163.pdf

Clearly, but that’s not what the parent said. Parent said you should encrypt it client side and treat the encrypted text as the new password.

They could send you a challenge salt that you hash together with your hashed password and send back as a response.

So that string is valid only once.

Doesn't mitigate the fact that this type of scheme turns the hashed password into the equivalent of THE cleartext password. It's usually compromised/dumped server databases you want to protect against.

No, the outlined scheme is actually correct. If there’s a call/response aspect, then the hashed nonce+password is not “the cleartext password”, it’s “the cleartext password for that particular challenge”, which makes it useless for other auth attempts, which would have different challenges.

The reason passwords are hashed is to prevent them from being usable to people who gain access to the backend database.

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.

I think we’re making different assumptions about how the challenge/response would be implemented. I agree that if there’s a shared secret and the nonce is simply appended to it and hashed, it’s a poor design.

"Nonce" is probably the word you're looking for.