I don't think it's trivial to find similar password for multiple reasons.

Comparing old passwords without plaintext is really hard and at best inexact.

Storing them plaintext (or even reversibly encrypted) is completely stupid, of course.

Even if these technical problems could be solved, sequences like: November6, December7, January8 are not "similar" but easily predictable.

Even this sequence is probably not hard to figure out if you look at a keyboard: Secret1 Drvtry2 Ftbytu3

Deeper though, what security threat is this actually mitigating? Bad passwords caused by rotation requirements that are needed because of bad company policies, training and practices? Is there a security equivalent of "yak shaving"?

How would you do the comparison? Wouldn't it require storing all the previous passwords in plaintext?

If only the hash and salted password is stored, as recommended, how would you know that "myOldPassword21" and "myOldPassword22" are similar ?

Same way you check if the password is correct. Check against the old hashes. When the user sets the new password, if it looks like it matches an iterative pattern (i.e. if it ends in a number) then test the previous few from that sequence against the old hashes. Note, this is still a terrible idea.

Cryptographic hashes of similar strings can't be similar.

You don't compare the hashes. When the user changes the password to "myOldPassword22", you hash "myOldPassword21" and "myOldPassword20" etc and compare those to the old hashes.

Do you know how many variations there could possibly be??

For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.

Combined with using a secure computationally-expensive password storage mechanism (eg: bcrypt or PBKDF2) and I'm not exaggerating: it now takes billions of years to verify a password change is allowed.

And this is trying to solve a compromised password problem. If there's no compromise, rotating passwords is pointless.

If the password IS compromised, rotating the password doesn't really fix it, it merely limits access -- maybe. It doesn't address the original means of the compromise (so you have to assume that's still there). It doesn't address backdoors installed. It doesn't address information stolen.

So this is a hell of a lot of work to accomplish .. basically nothing.

  >> comparable problem to "play every possible game of chess" for a computer to figure that out.

my_password + iterator is a very common password convention.

It would be a poorly programmed computer that didn't consider this possibility.

> For example, I could use: myoldpasswordA1 / myoldpasswordB2 / myoldpasswordC3. Probably obvious to a human my next one will be D4, but it is a comparable problem to "play every possible game of chess" for a computer to figure that out.

Two possible changes (forward/backwards) for two characters out of 15. 420 combinations. Not exactly billions.

> Two possible changes (forward/backwards) for two characters out of 15.

Yes, but you can only cut down the sample space in this way because you can look at "myoldpasswordA1" and know that the 'A1' characters are the iterators. A computer doesn't know that.

My figure is for testing all possible ways of changing two characters by one each (and the ways of changing only one character are a tiny subset of that). This doesn't catch people who change 3 or more characters, or who change characters by more than 1, but at that point is it really still so easy to guess?

You're focused on the wrong problem!

Why does someone have an old password in the first place? You should be asking how it got compromised, who knew the credentials, if it was compromised while still active, and if so, how many backdoors were installed, what data/systems were compromised, and how do you prevent this from happening again.

None of the problems could have been avoided if only there was a better password iteration detection algorithm.

> Why does someone have an old password in the first place? You should be asking how it got compromised, who knew the credentials, if it was compromised while still active, and if so, how many backdoors were installed, what data/systems were compromised, and how do you prevent this from happening again.

All true. Nevertheless, there are cases where someone gets a one-off copy of a password - perhaps overheard. If you force them to actively install a backdoor then you increase the costs of attacking greatly. It's not about perfect security, it's about the cost/benefit - a lot of crime is crime of opportunity, especially internal fraud.

> If you force them to actively install a backdoor then you increase the costs of attacking greatly.

I think that it's my fault, but I can't understand this sentence. Doesn't forcing someone to install a backdoor decrease security? The only reading that makes sense to me is "If you make it so that it's user action, rather than inaction, that results in the installation of a backdoor …"?

(For what it's worth, although I disagree with you, I respect your dedication to arguing this determinedly but civilly.)

What I meant was: "if you force an attacker who obtains a one-off copy of a password (perhaps overheard) to actively install a backdoor (in order to have the capability to perform an attack at some later time - as opposed to being able to passively maintain that capability by simply remembering that person's password pattern) then you increase the costs of attacking greatly"

You make the modifications and store those hashes as well.

Can't have a new 'similar' algo for past pws, obviously.

If you store N variations, a random guess has N chances to hit one. Once an attacker knows a variation, they may be able to use it to narrow down on the real password.