It does not seem that difficult to detect when the new password is very similar to the old password. Do it on the client side on a page that the user enters both the old and the new. And give the user guidance to use a password manager and auto-generated password.
Not true. If you have the new password, and old salt and hash, you could change a few things in the new password (common things, like increment or decrement a number if there is on the end), and hash it with the old salt. All this would be done when updating the old password.
Proper password change procedures generally require the old password to update it, so the code running on that page theoretically has access to both and can run a similarity check.
But my opinion is that ensuring creative passwords with an unclear similarity rule will only result in creative bypasses of that rule.
Unfortunately it's an easily defeated method. The motivated user just changes their password to a temporary value, and then again to the incremented value.
A user can also trivially defeat any password system by publishing their password to Facebook.
The purpose of preventing similar passwords isn't to prevent a user from defeating themselves, it's to prevent an adversary from defeating the user.
Now you can rightfully argue that blocking similar passwords isn't an effective measure against an adversary, and this article kind of suggests that... but it is possible to implement such a system.
I've been at places where the old passwords seemed to be kept around, so that it was detected whether or not you were switching to the password you used six or seven passwords ago.
This is done by keeping the old hashes around. The new password hash is compared to prior hashes to be sure it doesn't match any of them. This only catches exact matches on re-used passwords.
Or, the current plaintext password is compared to the new plaintext password (normally a password change requires the current password) so you can do more sophisticated similarity checks, but only compared to the current passord, not any older ones.
The whole point of this article is that rotating passwords is pointless. It doesn’t solve the original problem. MFA is the solution to that problem, not password rotation policies with Byzantine change requirements.
A better focus is on plugging the hole where the password was stolen. If it’s not plugged the password will simply be stolen again.
The reason rotating passwords is pointless is because people always end up changing their password to some easy to guess variation of the original password. If you prevent that from happening, the new password won't be guessable if you have the old one.
If I recall correctly: Active Directory can be setup so that the last few passwords cannot be reused, otherwise people would just cycle through two passwords. I am guessing that people would simply use a variation of their second to last password to come up with a new password under your proposal.
A long time ago as a student I worked at a company that had mandatory password changes every month. So I just used the same password and appended the current month to it.
