11

When prompted to update their passwords after they've become stale (whether that's after 30, 60, 90 days — whatever is implemented by policy), many users simply increment the number that they may have been forced to add by the password policy.

I'm interested to know just how prevalent this practice is — not necessarily who's actually doing it.

Systems already keep a (hashed) password history to prevent immediate reuse. How bad would it be if I were to also keep a history of the ASCII sum of the plaintext and observe if that sum is incremented when the password is changed?

Nev Stokes
  • 458
  • 3
  • 10

3 Answers3

20

You can test whether or not certain users do this without saving any additional data which might potentially weaken security. Just check what their previous password would have been when they follow this schema and compare that to the old hash.

When a user updates their password, create permutations of the new password by taking each digit in the password and decrementing it by one. Then calculate the hashes of these permutations and check if they match the hash of the old password. For example, when I change my password to Pas5word!14 you would calculate the hashes for

Pas4word!14
Pas5word!04
Pas5word!13

When one of them matches my old hash, you caught me.

Philipp
  • 49,017
  • 8
  • 127
  • 158
  • 5
    This is also [how Facebook detects similar passwords](http://security.stackexchange.com/a/53483/16316). – Jan Fabry May 07 '14 at 17:25
  • 6
    Most password change dialogs require providing both your current and replacement password. Wouldn't taking advantage of that to do change analystics using the plaintext of both versions be a lot simpler than doing a bunch of hashes instead? – Dan Is Fiddling By Firelight May 07 '14 at 18:03
  • 5
    @DanNeely That works if your intent is just to preclude variations of the last password, but this method can be expanded to safely compare against the hashes of the last n passwords. For instance to check to make sure March's password isn't January's password + 1, and April's password February's password + 1 – PeterL May 07 '14 at 21:25
1

When the User must entered the old Password befor it change it to a new one, you could try to check how much are the new and old password the same. Because this can be done on the Clientside you don't need to save the History of the ASCII sums.

Serverfrog
  • 576
  • 7
  • 18
  • 2
    If you do it on the client side, it's possible for the user to disable the check and just send a false message claiming the PWs were different enough. – Dan Is Fiddling By Firelight May 07 '14 at 18:04
  • When you think of that the client would try to eliminate the passwordcheck, then mostly every try to check if the passwords are nearly the same would fail in some kind. Even the kind of check Facebook does (as seen in the comments of the other answer). One try to defeat that: let the client generate a hash which has no relationship to the password and the value is complete random, which is send to the server with the password. Then let the server validate the hash. It's only one wall more that the client must break. But a wall is a wall. – Serverfrog May 07 '14 at 18:13
  • 2
    You should never trust client side validation. Go ahead and validate client side as a convenience for the user, but it always has to be rechecked on the server if you want any reasonable guarantee of validity. – PeterL May 07 '14 at 21:36
  • 2
    Instead of `Clientside` you should say `before they are hashed` as this operation can be done server side securely. – SilverlightFox May 08 '14 at 09:07
1

Having a checksum (sum of characters) stored in addition to a hash will weaken the robustness against brute force extremely (especially if not using a short modulus). If this is a problem for you or not, we cant tell.

I would advice doing social research studies of that kind when they weaken the security of the system. Just use typical password filters which enforces more differences at password changes and be done.

eckes
  • 962
  • 8
  • 19