Hacker News Reader

Comment by unethical_ban | Hacker News Reader

In the best of systems, client-side encryption/hashing occurs.

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.

View on HN

I've used systems in the past that analyze them server side for similitude with previous passwords of your own (or perhaps only your last password? if that's the case, requiring current password would be enough, no need to store it in plain text).

They might also want to check it against a list of most used passwords.

I vaguely remember Microsoft doing this, e.g. "You cannot use your old password and just add a number to it", but I might be mistaken and it may have been only blocking setting the password to a previous one.

All they'd have to do to safely achieve that is, when you initially set your password to "foo" they will store 11 hashes (foo, foo0, foo1, foo2...). Then when you change your password, it's hash cannot equal any previous hashes.

Or, even simpler: if the plaintext of the new password ends in a number, try stripping (or decrementing!) that number and see if either of those hash to the same as the stored old passwword.

Oops, yes of course! And then it can be any incrementable (or not) character.

> In the best of systems, client-side encryption/hashing occurs

What does this protect against?

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

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.

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

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.

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.

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.

Reply on news.ycombinator.com