Hacker News Reader

Comment by jameshart | Hacker News Reader

> your password can't be anything like any of the previous ones (i.e. they're not stored hashed)

That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).

View on HN

Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed.

Developer: Similar passwords? Or Same passwords. Similar is hard.

M: Similar. Can't let people be lazy with their passwords.

D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but...

M: Good! Let's do that.

D: ...but that could be a massive amount of space for long passwords.

M: Okay, we'll just enforce short passwords then.

D: ...doesn't that more than negate all the benefit of preventing similar passwords when rotating them?

M: Doesn't matter, the CEO said he wants this. Hop to it!

Developer laments the stupidity of their life

Been there, fought that.

longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing

But a longer password would require more combinations for similarity than a short password.

Yes, that's the point being made.

Ah. Thanks for clarifying.

Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!

And further still, they don't need to _store_ all the hash variations

https://security.stackexchange.com/questions/53481/does-face...

Wow, it slipped my mind entirely that you could do the permutations when you create the new password but before verifying, rather than after creating a password. That's a great idea, and embarrassingly obvious in retrospect.

Why would they need to store the hash for all the combinations?

Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.

Depending on what is considered "similar", every extra password character may exponentially increase the number of similar passwords.

Well in my case, there was only an 8 character limit, so there was a least a bound on it. I didn't investigate how far you could deviate from an old password before it was allowed though.

It's funny because "DecemberSixteen" is very different from "MarchSeventeen" as a password from a characters point of view but is trivial to extrapolate if you know the guy has to change password every 3 months.

Though I'm pretty sure I've seen "Your password is too similar to a previous password" before, which suggests some kind of plaintext Levenshtein distance check.

"Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.

When I've seen that "your password is too similar..." warning, it was with a system that required entering my current password to set a new password, so no need to store a previous version in plaintext.

Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.

I think almost every system requires you to put in your current password to change new password.

Aren't passwords hashed on the client side before sending it across the network? That would make your way around not work (unless that's done on the client side also after verifying from the server that it's correct).

I've certainly never encountered a web app that hashes locally before sending. I suppose it could work if this was at the account creation or password management stages, but you couldn't implement it at the login stage for obvious reasons.

I'm having trouble imagining what scenario client-side hashing would protect against.

Man in the middle attacks fetching for plaintext passwords

-- edit: using a KDF would improve it even more.

If the client only sends the hash to the server, a MitM also only needs to capture the hash.

Sure, but if they've MITM:ed your trusted certs, aren't you already boned in so many ways?

Hashing it on the client side will make the hash the password. So the stored hash can be used as password by turning off the client side hashing, for instance by turning off javascript. You use https to avoid sending the password in cleartext over the network

That's unnecessarily complex. Just ask for the old password when doing an expiration reset. Validate the old one then compare that against the proposed new one.

Actually, that's a very good point - you did indeed have to submit the old and new passwords. I want to say that they checked against older passwords too, but I might be misremembering.

That doesn't help. Your new password might be the same as the twice-previous password.

You're certainly right (e.g. that's how Facebook can remember so many different variations of you password without storing the actual password itself), but if their engineers are capping the password field at 8 chars, I HIGHLY DOUBT that is what's going on.

If you really want to annoy me, use soundex[1] as a final normalization step.

[1] https://en.wikipedia.org/wiki/Soundex

Doesn't that decrease the benefit of storing a hash? You probably know the process through which the derivative hashes are generated, which is not known-plaintext but seems kinda iffy still.

I think it would decrease the benefit, yes.

If you store the hash of the password, plus the hash of a hundred "similar" passwords, then the hacker only has to brute-force one to find that they are on the right track, and then brute-force "similar" combinations.

Unless you do it the other way around: Generate a list of all passwords similar to the one the user just entered and see if that matches any previous hashes. This is how Facebook's password check works [0]

[0] https://security.stackexchange.com/a/53483

Supposedly, you'd only be able to get feedback about the similarity of a password in a state where you're already authenticated. So I guess this would help an attacker get the password when they've already gained access in some other way. But that's a big assumption.

Yeah, they probably stored old hashes, but I find it hard to believe they stored variations of old ones as well. Maybe they did though!

Reply on news.ycombinator.com