This wouldn't work either. It would just make users bounce between 2 passwords: foo100 -> bar200 -> foo101 -> bar201 -> foo102, etc.
back
1 comments
The one system where I saw this implemented in practice used my last x passwords to check. I think "x" was 50
Because it had a fairly short password cycle, I'm sure most users ended up with something like "password1!TwentyFour" then "password1!TwentyFive".
Me: I just changed my password 51 times when it was time. I'm not sure what point I was proving, but I was proud of myself.
You can't stop someone's next password from being a variant of their next-to-last one unless you store them unhashed.
Couldn't you hash some obvious variants of the new password to test against? I always assumed this system did that since it would reject some passwords that were close to old passwords.
Of course, it's also possible they stored the clear text password, I have no real way of knowing.
> Couldn't you hash some obvious variants of the new password to test against?
This is impractical if you're following good password storage practices. Assume the user's new password is 16 characters long, and that only the 95 printable characters are allowed in passwords. Then to test that the Levenshtein distances between it and the user's last 5 passwords are all greater than 1, the server would have to compute (5 * (1 + 95 * 17 + 16 + 94 * 16)) = 15,680 different hashes, which will take quite a while if you picked a secure iteration count for your password hashing function. And even if you did this, it still couldn't detect mypassword100100 -> mypassword101101 -> mypassword102102, etc. (Making sure the Levenshtein distances are greater than 2 would require checking millions of hashes.)