Comment by free652

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.

Not if they ask for the current password at the same time.

https://news.ycombinator.com/item?id=44265372

Similarly of new vs current password is simple enough by just requiring the current password as part of the password change call. Which is a good idea anyway so someone can't just walk up and change your password if you forget to lock things over lunch.

Similarly vs older passwords is what would be an issue.

It probably requires some sort of decreased security (if the password hash is truly slow & secure, it would be hard to enforce dissimilarity); but there might be other methods that leak less than cleartext (like salting and storing hashes of overlapping/separate n-grams from the previous password and checking for number of similar n-grams; etc). Or as another commenter suggested checking all passwords within edit distance 1 (though if you can do that, your password hashing algorithm is likely too fast).

Interesting perspective. Wonder why so many SaaS service currently enforce this.