How do servers check that a new password isn't similar to one used before?

Where I work, whenever we change our password, the system checks to make sure it’s not the same or even very similar to any previously used passwords.

I know passwords are always supposed to be stored using one-way encryption, meaning it’s impossible to determine the original password from the ciphertext (encrypted version). Also, encryption means even a single character change causes a dramatic change in the ciphertext

So, how do they check that my new password isn’t similar to a previously used one? Do they just check variations of the new password against the old one (encrypt the variation, compare to encrypted version of the old one)? Or is there some trick that lets them create (encrypted) variations of the original password from the ciphertext?

If they are really only storing the salt and hash. Then it has to be at the time you type in a new password they get the hash of variations of the new password and see if it matches old hashes. Once the password is verified they should forget the password and only store the hash. If there are tricks to get variations of the password from the hash then it is a broken hash algorithm and they should move to something secure.

History is full of bad security so it is possible that they store old passwords to check. But hopefully not.

Are you talking about your Windows Active Directory account password? Windows can store up to 24 passwords to check to make sure you are not using the same one.

Similarity is different than the same; to determine similarity, they’d have to either have the old passwords stored in a way that they can tell the difference between say “PAssword01” and “paSSWORD01”, meaning the passwords themselves, or some sort of janky hash that would show that similarity.

Ideally, like gazpacho says, they’d only be able to determine whether the password was the exact same, because the hashes would match.

Based on my experience, this is more likely. There are tonnes of bad password practices out there.

Don’t you need to supply both old and new passwords to do the change? Otherwise someone could change your password if you are away from your computer while still logged in. In that case they can store your old password in memory just long enough to do the comparison.

In most sites that I see, when changing the password you have to enter the old one first. So the routine verifying the new password has access to the unencrypted old one. However, it can not check for similarities on older passwords, only check to verify that an old one is not being reused.

I’ll just say that, in my experience, this isn’t always the case. I’ve had sites that will not let me reuse a previous password, even if it’s not the most recent one, so at least some sites are somehow storing a history of old passwords.

They can cheaply store your last X passwords, hashed, to make sure you don’t reuse them. Comparing similarity of old passwords would be harder, of course.

It’s not very computationally expensive to check the number one thing that people do for password recycling - stick a digit on the end (or increment a digit on the end)

You could experiment to see what sorts of things the similarity detector can actually detect. Does it know that ‘b4dpassword’ is similar to ‘badpassword’, for instance? Or ‘thnkinghard’ is similar to ‘thinkinghard’?

You could use the new password and try some common permutations of the new password and compare it to old hashes. If they don’t match you accept the new password store the new hash and hopefully forget the new plaintext version of the new password.

I haven’t seen “too similar” comparisons before, but I suspect the ones that do use this approach.

I guess they could also run some process of swapping out one letter at a time on the new password and comparing the hash to the old password. If “similar” means only one character changed or added, that’s around 2000 variations for a 10-character password (~100 available characters for each position in the password plus inserts/deletes anywhere within it). That’s not a ridiculous amount of processing needed.

I agree that it would be possible to store the hashes of a bunch of permutations (letters swapped/dropped, digits swapped/dropped, etc.) of your password each time you set it, and then compare hashes of permutations of your new password against them.

I am somewhat skeptical that this is actually happening, though. I bet if some site is telling you your password is “too similar”, they are likely storing passwords in the clear.

I totally didn’t think about that. Yes, we do have to supply our old password as well. I’d be very surprised if they’re using that to create the variations, though. Passing the cleartext of a still valid password to another routine or storing it in memory, even temporarily sounds incredibly dangerous, even for a highly protected server like the the domain controller.

I’m pretty sure they’re not storing the cleartext of the password, or doing other stupid/shortsighted stuff. This is Amazon and they tend to be pretty good about security.

If the server can tell anything whatsoever about your password, then obviously it’s not secure. Secure protocols never transmit the password to the server.

You don’t need to send the old password to the server to look for similarity. Whatever local thing is taking the new and old passwords and hashing them to send to the server could also do other string operations on it to check for similarity.