In many places, there's a policy that force the user changing it's password once a few months. The logic here is, that even if the password have leaked somehow, it'll be abused only for a relatively short period of time. So that a note with your password you threw to your bin now, will not come and hunt you in five years.

But what this policy is missing IMHO is, the people factor. What many people usually do when forced to change their password, is to choose a new password not to too far from the original one. Since it's hard to memorize the new password every month. For example


or so. So an attacker with a minimal amount of sense, would activate john-the-ripper or equivalent, and find out your password in no time. Heck, the entropy of the new password given the old password is typically so low, so that you can even bypass a password system that alerts the admin if you entered the wrong password three times in a row. You'll probably find the new one within 10 trials, and given that the user logs in once a day an attack will be able to find it out within a month.

So I'm asking, will a policy that force users to change their password once in a while actually provides more security than its cost?


3 Answers 3


As you note, when you force users to do something, they do not like it, because it makes things more difficult for them. Users rarely focus on security; it is not their job, and, instead, their job implies going through the hoops that the security department comes up with. So they react logically, by taking measures which make their life easier.

Classical countermeasures employed by users include:

  • simple derivation of the new password from the previous one (but there are password management interfaces which try to prevent that: "the new password is too similar to the old password");

  • cycling through a list of passwords, usually reduced to two passwords; the user just swaps his "normal" and "alternate" passwords whenever a password change is requested (to prevent that, the password management system must remember previous passwords, which can itself be a security hazard);

  • the all-time favorite of writing the passwords down on a sticky note (cunningly hidden under the keyboard);

  • getting passwords from a "natural list", e.g. current players in a soccer team (it is not easy to make an automated test which will detect that, but a human attacker with half a neuron will handle that easily).

So the increase of security through regular password change will be, at best, dubious. Its main virtue is to avoid the establishment of a local "traditional password" which employees communicate to each other for years, and previous employees keep on remembering.

Theoretically, regular password change might give users a sense of "something worth protecting is going on" and prompt them into being more cautious with their passwords; in practice, I have never witnessed that.

  • 3
    I'm not sure it's that easy to prevent effectively new password which is too similar to old password (password.reverse(), password[i].toupper() etc etc). Sep 15, 2011 at 12:08
  • 2
    Any system that can tell you whether your password is too similar to the old one is likely to be insecure because it probably stores your old password in plain text!
    – user21820
    May 12, 2016 at 14:56
  • 1
    @user21820 Not so at all. You just come up with a list of "too close passwords" based on the new password (which you do have as plain text). You then hash every password in that list and compare it to the current hash. If any matches voilà too close for comfort. That said I'd say it's impossible to come up with an algorithm that's easy to explain to the end user, produces not too many false positives and still catches a large number of trivial algorithms.
    – Voo
    Apr 3, 2017 at 17:08
  • @Voo: That's true. But I'd be surprised if any such system I've come across actually does what you say! Hence my "likely" and "probably". =)
    – user21820
    Apr 3, 2017 at 17:49
  • 1
    @user21820 Most systems I have seen ask for the current password when you are changing the password (the exception mostly being if the password change is initiated by a system administrator through a privileged interface). So there is no need to store the current password in any reversible fashion, because you are asking the user to type it in! Now, a system that tells me that "this is too similar to your fourth generation past password" would give me pause, but as discussed by Voo, doesn't necessarily imply that old passwords are stored in a reversible fashion (including plain text).
    – user
    Apr 4, 2017 at 8:04

One of the aspects which isn't mentioed yet, is in my opinion the most important one - awareness of the user. I can tell you from experience that whenever you can give users a demo of what the impact would be of a bad password and make them aware of it, they will start to value and understand it. Awareness is exactly the reason that we, security people, understand the problem. We know the impact, ordinary users don't.

Show it to them in a workshop by breaking in as they witness it, so they understand the root cause of the password policy.


In addition to some of the reasons above, changing passwords also helps keep hackers from cracking stolen encrypted credentials and using them. If the time between resets is smaller than the time it will conceivably take to crack the hash, the attacker cannot use the password.

For example, imagine if a bank loses their entire encrypted database of passwords, but doesn't realize it. The bank requires the use of passwords that are complex in nature, and at least 10 characters in length, and requires a reset every 90 days. The hackers have at their disposal a system which will crack an average 10 character complex hash within 120 days.

So, if the users are changing their passwords every 90 days, the stolen encrypted credentials will 'expire' before the hackers have the time to crack them.

Obviously, modern cracking systems can do a lot better than 120 days, but it's still a good example because of one thing: How many user accounts do the hackers want to have cracked before they go do something evil? One might net them $200 bucks, but 20,000 will net them $2 Million. Hiding in those numbers is a good risk management method as well, as getting 20,000 username/password combinations would easily take months.

*Note: All the times I give are guesswork. There are a lot of variables that go into cracking a password, and not all of them are predictable.


  • 1
    Huh? Why would they expire. After 120 days the hackers will find out the password for "Joe" is "foo1", they'll try "foo1", "foo2" and "foo3" and they'll get his password eventually. Sep 15, 2011 at 18:58
  • That's still a brute force attack though. How does the attacker know it's foo2? It could be foo1bas, or goo1bar, or any number of other small incremental changes to a password. Though maybe I'm too numb to individual users since I do security for 100s, and don't pay enough attention to spear-phish type attacks.
    – MToecker
    Sep 15, 2011 at 19:37
  • 2
    of course that it can be different, but the entropy of the new password given the old password is very low, and the bad guys can probably figure it out in 100 guesses in the worst case. That's my point exactly. The theoretical benefit of "brand new password every X days" is nonexistant, since the password is probably one character away from the old one. Sep 16, 2011 at 12:59
  • 5
    @MToecker In my experience, three out of the three users I've asked just increment a number each time they change their password. The number is the only number in the password, AND it's a single-digit that rolls over. Now, I admit my sample-size is small, but given that, it would be really easy to have a computer try all 10 passwords for you, or even do it by hand.
    – Patrick M
    Mar 16, 2013 at 16:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .