> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious)
Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.
If they’re using some special hash algorithm that retains most of the information of the original password and allows them to determine that “password1” and “password2” are similar and “blahblah7” is not, their approach is hopelessly broken too.
Technically you could tokenize and dictionary plus edit distance check the password in the client if you have the plaintext, or use malleable hashing. Check entropy while at it. Of course that will not stop a determined policy ignorant.
Requiring a plaintext password storage somewhere is an instant regulatory fail in ISO 27002 and PCI DSS standard. You can technically store the passwords encrypted, but attacker is liable to steal your salt/key, and protecting the passwords in transit strictly requires strong PKI. We know users cannot determine that anyway and get phished/MITMed.
Plus it's kind of mean. If your users are determined to ignore your policy, maybe it's a bad policy or you need to tell them to stop doing that.
Checking for x latest passwords requires just storing their hashes.
Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity?
That's literally impossible without plaintext passwords isn't it. That is insane.
The hashing has to happen serverside, which means the server will temporarily have the plaintext in memory. While there, you can mutate the string by adding/removing/chanigng characters, to get a bunch of strings that are similar. Then you compare all of those to the old hashes you have stored. It will catch people doing common stuff like incrementing a number at the end on every reset.
> That's literally impossible without plaintext passwords
No, it’s not. It’s called locality-sensitive hashing. You’d store the last 10 LSH hashes in a database next to the SHA-256 hashes. Compare those LSH hashes to the LSH hash of the new password. Match? Reject the new password.
It’s also used to identify photos that are similar:
Surely even having an LSH stored is a potential compromise - e.g. if my password happens to have the same LSH as somebody else because I've used "Secret-123" and they've used "Secret123", then you've presumably got a better chance of guessing what my password is than if the LSHes weren't stored (if you can't get from me directly, you can try to get it from others who have the same LHS).
You’re assuming an attacker can access this database somehow? And that the LSH of “somebody else” is reversible? I’ve don’t understand the vulnerability you’re describing.
Yes, obviously, I'm just saying it's a potential vulnerability that doesn't exist if you don't store the LSH. The LSH doesn't need to be reversible - I'm just saying that you now have a situation where if you can find multiple people with the same LSH, if one their passwords becomes known to an attacker for any reason (the attacker could be one of those people!), the other passwords are now much easier to guess.
Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.