You can't stop someone's next password from being a variant of their next-to-last one unless you store them unhashed.
back
1 comments
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.)