A better method would be to save previous password hashes when a password is changed, then check hashes of permutations of the new password against the previous ones.
It's a storage versus computation time trade off, and with something like bcrypt doing the hashing, hashing 1-10k passwords will be too slow to provide real time feedback as a user is changing their password. On the other hand, storing even 10k hashes per employee per month of employment just isn't that much storage.
That would only be true if it didn't keep history. Let's assume my previous two passwords are "love123" and "hate098". If I try to use a new password "love124", then the permutation checker (which, for the moment, knows the new password in plaintext) should check the hash of "love123" and reject it.
Oh. If you write a permutation checker that happens to output one of your old passwords, then yeah, that'd work. I wonder if that's feasible. It's an interesting idea. Computing hashes is relatively cheap, so I wonder if, say, 1,000 "permutation checks" would be enough.
(Although if you're using bcrypt to store passwords, which you should be, then apparently it's not so cheap.)
But.. 26 letters in the alphabet + ten digits = 36... and 36^n grows really, really fast. So maybe you'd need way more than 1k permutation checks.
It does, because if the new password is similar to the old one, you can either modify the old one to get the new one or modify the new one to get the old one.
But if you have hashed the password correctly (i.e. a one way hash) you shouldn't know what the previous passwords are. This means that you would only be able to test if the password was the same, not similar.
