Comment by eru
2 days ago
In practice, that's probably how it's done. But in theory: no.
Assume you keep the hashes of the last few passwords around. Then you can search in the 'neighbourhood' of the new password to check if any of this matches the old password's hash.
By neighbourhood, I mean something like within a small edit-distance, where the kind of edits depend on what measure of similarity you want.
If you only care about similarity to the last password (or care about that one specifically), then that's even easier: during the password change procedure you can have clear text access to both the old and the new passwords without storing them anywhere unhashed: because the user has just entered both passwords.
Wouldn't this be super slow if you're using a proper password hashing algorithm?
Yes, if it takes one cpu second to hash a password, it'll take a while to try a few like this.
You can do a quick check against the last password (which you have in clear, because it was just entered), though.