3 ms·

To prevent people doing this just throw in a string similarity algorithm into your password-change UI. if similarity(old_password,new_password) > 50% then reje

by ukj 10y ago

To prevent people doing this just throw in a string similarity algorithm into your password-change UI. if similarity(old_password,new_password) > 50% then reject password change...

cowsandmilk 10y ago
Or just require good passwords in the first place and stop this bullshit.
JoeAltmaier 10y ago
...or stop requiring it altogether.
tomjen3 10y ago
Then I will just change busstop04! to trainstop9? and keep altering between them. Seriously you cannot invent a password scheme where people can choose passwords that will not be vulnerable to this.
kwhitefoot 10y ago
How does that work? Or, rather, if that can work the system has even bigger problems because you must be storing the passwords in plain text instead of salted hashes.
- Sean1708 10y ago
  It could be done on the client if you get them to enter their old and new passwords.
  - tzs 10y ago
    If they are going to have a "new not similar to old" policy, it should probably be done on the server rather than the client, because the client is less trustworthy. A password change dialog needs to be asking for the old password anyway and then verifying that it is correct to protect against people who step away from logged in sessions having their passwords changed by pranksters or worse. I doubt "new not similar to old" policies actually accomplish much. If they are implemented securely using standard technology they will only be able to check the proposed new password against the current password. That just means that instead of having a sequence of similar passwords, P1, P2, P3, ..., users will have two such sequences interleaved: P1, Q1, P2, Q2, ..., where all the P's are similar and all the Q's are similar but the P's are not similar to the Q's. There's probably a way to do a similarity check between two passwords given just hashes of the passwords (for instance, using homomorphic encryption), but that kind of thing is more research level than deploy live level, I believe. If/when that becomes practical, then a no similarity policy could go back as far as you are willing to keep old password hashes around without being any less secure than a no reuse policy going back as far.

by ukj 10y ago

To prevent people doing this just throw in a string similarity algorithm into your password-change UI. if similarity(old_password,new_password) > 50% then reject password change...

cowsandmilk 10y ago

Or just require good passwords in the first place and stop this bullshit.

JoeAltmaier 10y ago

...or stop requiring it altogether.

tomjen3 10y ago

Then I will just change busstop04! to trainstop9? and keep altering between them. Seriously you cannot invent a password scheme where people can choose passwords that will not be vulnerable to this.

kwhitefoot 10y ago

How does that work? Or, rather, if that can work the system has even bigger problems because you must be storing the passwords in plain text instead of salted hashes.

Sean1708 10y ago
It could be done on the client if you get them to enter their old and new passwords.
- tzs 10y ago
  If they are going to have a "new not similar to old" policy, it should probably be done on the server rather than the client, because the client is less trustworthy. A password change dialog needs to be asking for the old password anyway and then verifying that it is correct to protect against people who step away from logged in sessions having their passwords changed by pranksters or worse. I doubt "new not similar to old" policies actually accomplish much. If they are implemented securely using standard technology they will only be able to check the proposed new password against the current password. That just means that instead of having a sequence of similar passwords, P1, P2, P3, ..., users will have two such sequences interleaved: P1, Q1, P2, Q2, ..., where all the P's are similar and all the Q's are similar but the P's are not similar to the Q's. There's probably a way to do a similarity check between two passwords given just hashes of the passwords (for instance, using homomorphic encryption), but that kind of thing is more research level than deploy live level, I believe. If/when that becomes practical, then a no similarity policy could go back as far as you are willing to keep old password hashes around without being any less secure than a no reuse policy going back as far.