A lot of users, myself included, increment the last digits of a password when it is required to be changed on a regular basis - e.g. 30/60/90 days.

Regardless of whether forced password changes are an effective security control, is there not a way to identify similar passwords and prevent them being set; and if there is a way, why is it not routinely employed?

For example:

  1. Consider the new password (plain text) and the hash of the current password

  2. Identify any digits at the beginning or end of the new password and sequentially generate 100 variations (e.g. Password55 -> Password54,Password53 etc,Password56,Password57 etc.) to identify common increments.

  3. If any of the resulting hashes match the current hash, deny the password change on the basis it is too similar to the existing password.

This feature doesn't appear to be an available setting in Windows (at least) and I'm curious to understand why.


  • This might not be an issue across small organizations, but with large organizations that, at any given time, may have 10% of their population changing their passwords I suspect this could consume a chunk of resources. Also - is it really any more secure? Nov 7 '16 at 21:11
  • This is a very specific case. The only reason somebody would implement it would be when the password policy is to not increment the previous password. Also, keep in mind that most of the passwords are strings(I say most because some devices have numeric passcodes) and are handled as strings not integers... So this kind of restriction wouldn't really come into picture.
    – Limit
    Nov 7 '16 at 21:12
  • 3
    Some sites do try, e.g. Facebook security.stackexchange.com/questions/101827/…
    – paj28
    Nov 7 '16 at 21:24
  • 1
    I can't speak to Windows, but with UNIX/Linux, you do have things like pam_cracklib which provides more stringent controls over passwords like you suggest. I'm fairly sure other third-party authentication schemes (I'm thinking LDAP) provide this feature as well.
    – MikeA
    Nov 7 '16 at 21:36
  • 1
    One of the "problems" with rules like this tends to be, the more complex you make it for the user, the more likely they are to write the passwords down anyways. It just may be this level of complexity generates more issues than benefit.
    – MikeA
    Nov 7 '16 at 21:42

I guess this is wilde guessing which is not worth it. Should you only identify numbers? How may? Why not identify characters? If I am setting my password to be "secret10", the system would save Hash("secret10") as my password hash and Hash("secret11"), Hash("secret12")... to be hashes, which I would not be allowed to use in future. But this system already breaks when I set my next password to "Secret11". The system is not capable of identifying the changed upper case! Comparing hashes with even the slightes logic is not possible. Since even the slightest change will break the Hash. And if you want to design a secure system based on passwords, it is more impartant to use hashes than to check for changes in the passwords.

  • It's not difficult to apply several transformations to the new password to see if it is similar to the old, especially since at password change time, the user enters both. Facebook, for example, actually does this.
    – Ben
    Nov 8 '16 at 13:50
  • Yes, but you can only compare the current with the next password. This is way so many users have alternating passwords! By the way. Even Window$ does this. Linux does this, too. It is no great invention of our beloved facebook security company.
    – cornelinux
    Nov 8 '16 at 18:05
  • But this question asks about an incrementing sequence of passwords, not alternating back and forth between passwords. Even if you add that complexity, it's possible to compute ~100 hashes of slightly modified input passwords, and compare to the last 10 stored passwords or something. I've seen that suggestion a few times before on this site, I'm too lazy to search at the moment.
    – Ben
    Nov 8 '16 at 18:37
  • The OP asked, why it is not routinely employes?/implemented. And my point was, that it is not easy to identify a sequence. In fact it is easy to hide the sequnce, since it is ease to add a slight chaning/alternating factor, which will immediately break the hash for the other passwords your system would calculate. But I am repeating my self.
    – cornelinux
    Nov 8 '16 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.