3 ms·
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 'neigh
by eru 1y 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.
- apitman 1y agoWouldn't this be super slow if you're using a proper password hashing algorithm?
- eru 1y agoYes, 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.