7 ms·
> 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 ch
by jameshart 10y ago
> 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).
- makmanalp 9y agoDoesn'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.
- SamBam 9y agoI 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.
- MikeTV 9y agoUnless 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 https://security.stackexchange.com/a/53483
- dainichi 9y agoSupposedly, 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.
- Crespyl 9y agoThough 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.
- Johnny555 9y agoWhen 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.
- thewhitetulip 9y agoI think almost every system requires you to put in your current password to change new password.
- wapz 9y agoAren'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).
- rypskar 9y agoHashing 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
- matthewmacleod 9y agoI'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.
- joshvm 9y agoYeah, they probably stored old hashes, but I find it hard to believe they stored variations of old ones as well. Maybe they did though!
- sushid 9y agoYou'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.
- kbenson 9y agoManager: 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
- Imagenuity 9y agoBeen there, fought that.
- gpawl 9y agolonger 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
- squeaky-clean 9y agoBut a longer password would require more combinations for similarity than a short password.
- kbenson 9y agoYes, that's the point being made.
- gpawl 9y agoAh. 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-facebook-store-plain-text-passwords/53483#53483 https://security.stackexchange.com/questions/53481/does-face...
- jlg23 9y agoIf you really want to annoy me, use soundex[1] as a final normalization step. [1] https://en.wikipedia.org/wiki/Soundex https://en.wikipedia.org/wiki/Soundex
- Osiris 9y agoThat'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.