626

Where I work I'm forced to change my password every 90 days. This security measure has been in place in many organizations for as long as I can remember. Is there a specific security vulnerability or attack that this is designed to counter, or are we just following the procedure because "it's the way it has always been done"?

It seems like changing my password would only make me more secure if someone is already in my account.

This question was IT Security Question of the Week.
Read the Jul 15, 2011 blog entry for more details or submit your own Question of the Week.

12
  • 42
    @Bill, thanks for this great question! We love rocking the boat and questioning "accepted wisdom"...
    – AviD
    Commented Jun 22, 2011 at 17:10
  • 210
    It certainly makes sure that half the office has stickies with their password on their monitor or under their keyboard. Commented Jun 22, 2011 at 19:44
  • 41
    A better question: If this is necessary, how many of those same admins are rotating their service account passwords that typically have way too many permissions? Most places I've worked set those to never expire.
    – JohnFx
    Commented Jun 22, 2011 at 22:27
  • 14
    I hate this rule and have argued against it a lot. blog.damianbrady.com.au/2008/07/02/… for more details (in a comment for 0 rep)
    – Damovisa
    Commented Jun 23, 2011 at 2:04
  • 50
    I convinced the IT dept at my last job to make a tradeoff. We got rid of the password expiration policy in favor of stronger passwords. Everyone loved this decision, as they were able to actually remember their new password without keeping it posted to their monitor. Plus, their new passwords were more secure. Commented Jul 3, 2011 at 19:59

23 Answers 23

368

The reason password expiration policies exist, is to mitigate the problems that would occur if an attacker acquired the password hashes of your system and were to break them. These policies also help minimize some of the risk associated with losing older backups to an attacker.

For example, if an attacker were to break in and acquire your shadow password file, they could then start brute forcing the passwords without further accessing the system. Once they know your password, they can access the system and install whatever back doors they want unless you happen to have changed your password in the time between the attacker acquiring the shadow password file and when they are able to brute force the password hash. If the password hash algorithm is secure enough to hold off the attacker for 90 days, password expiration ensures that the attacker won't gain anything of further value from the shadow password file, with the exception of the already obtained list of user accounts.

While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups. Ideally, of course, everyone would be just as careful with the tape that has the backup from 6 months ago as they are with the production data. In reality, though, some older tapes inevitably get misplaced, misfiled, and otherwise lost in large organizations. Password expiration policies limit the damage that is done if an older backup is lost for the same reason that it mitigates the compromise of the password hashes from the live system. If you lose a 6 month old backup, you are encrypting the sensitive information and all the passwords have expired since the backup was taken, you probably haven't lost anything but the list of user accounts.

20
  • 46
    The problem is that with modern EC/GPU setups, cracking even strong passwords can be done at ludicrous speed very cheaply. Combine the raw brute force with gigabytes of word lists, custom character sets, and pre-generated hashes that you can look up (for free or very cheap), and that 90 days is a perfectly large window for cracking passwords offline.
    – Marcin
    Commented Jun 22, 2011 at 21:02
  • 14
    @Marcin - True. Brute force hash attacks have become much faster and older systems with insecure hash algorithms doing relatively few iterations are unlikely to hold up for 90 days. If you're using SHA-2 and doing thousands of iterations, on the other hand, your hashes should be strong enough to hold up for 90 days. Commented Jun 22, 2011 at 21:15
  • 15
    If you're assuming that a backup has leaked and the attacker has read access to the complete filesystem, ssh private keyfiles should be a much bigger concern than shadow passwords.
    – Ben Voigt
    Commented Jun 23, 2011 at 8:48
  • 170
    So, in other words, it tries to prevent a hypothetical attack (which, if it happens, means you've got bigger problems to solve anyway), but opens up a host of actual, severe vulnerabilities (Need a password? Just pick one, they're plastered all over the place. Oh, and they're leaving the company in the trashcans, too. Not valid, you say? Well, this guy had password letmein22011 for the second quarter of 2011, wonder what his password is now...). Not a very good tradeoff IMNSHO. Commented Jun 23, 2011 at 12:00
  • 65
    While competent admins are going to secure the actual shadow password file, organizations as a whole tend to be more lax about backups, particularly older backups. . . . this is why competent admins ENCRYPT THEIR BACKUPS. (It saddens me that I'm the first person to leave this comment in the 18 months since this answer was posted)
    – voretaq7
    Commented Dec 19, 2012 at 15:07
222

I have argued before that it doesn't improve anything. From that post:

Obviously the attacker does not know your password a priori, or the attack wouldn’t be brute-force; so the guess is independent of your password. You don’t know what the attacker has, hasn’t, or will next test—all you know is that the attacker will exhaust all possible guesses given enough time. So your password is independent of the guess distribution.

Your password, and the attacker’s guess at your password, are independent. The probability that the attacker’s next guess is correct is the same even if you change your password first. Password expiration policies cannot possibly mitigate brute-force attacks.

So why do we enforce password expiration policies? Actually, that’s a very good question. Let’s say an attacker does gain your password.

The window of opportunity to exploit this condition depends on the time for which the password is valid, right? Wrong: as soon as the attacker gains the password, he can install a back door, create another account or take other steps to ensure continued access. Changing the password post facto will defeat an attacker who isn’t thinking straight, but ultimately a more comprehensive response should be initiated.

So password expiration policies annoy our users, and don’t help anyone.

21
  • 18
    I would agree with this except in the instances of non-admin users. Most people probably don't have the authority to create back door accounts etc. When gaining access to a system my goal may not to try and take it over, but to gain access and steal information. As long as I have the account password, I can have access, but I don't want to do anything that might look suspicious (like creating an account). As long as the user doesn't change the password, I don't have to try and hack the account again. Changing the password to something non-predictable causes extra work for me. Commented Jun 22, 2011 at 14:38
  • 51
    This is plain wrong. We know that the attacker might have a hash of your password (Which is the reason for this policy in the first place)--which essentially gives him your password given enough time, regardless of the method he uses to crack it with. Replacing your password will thus invalidate the information the attacker has. The answer above sums it up. Commented Jun 22, 2011 at 20:29
  • 27
    Most users increment a number at the end of their password. I've worked in a bank and a common password was the name of the city followed by the number of the current month. Also, since most systems are inherently insecure, especially in a Microsoft Windows environment, it does not really matter if the user is limited or not, and it most likely is not that limited anyway.
    – Signal
    Commented Jun 22, 2011 at 20:39
  • 17
    @Kevin: how about a Unix system. You get into a user's account, and edit .profile to include "alias passwd=$HOME/.tmp/passwd" or just prepend $HOME/.tmp to the $PATH where the passwd under .tmp is a shell script which emails the password to my throw-away hotmail account and runs the system password command? No elevated privileges required, but there's now a simple back-door in place which keeps the account compromised.
    – dannysauer
    Commented Jun 22, 2011 at 22:57
  • 15
    @BenVoigt During a password change, you typically prompt for both the old and new password. So, you have both available, and can check for similarity.
    – derobert
    Commented Aug 30, 2012 at 16:44
158

Before answering whether it does help or it does not help, it makes sense to look at specific scenarios. (That's often a good idea when dealing with security measurements.)

In what situations does a forced-password-change mitigate impact?

The attacker knows the password of a user but has no backdoor. He does not want to be discovered, so he does not change the password himself.

Let's see if this scenario is likely:

How might he have learned the password?

  • The victim might have told him (e. g. a new intern who should start working before he gets his own account setup, another person who should level an account in an online game
  • The attacker might have watched the keyboard
  • The attacker might have had access to another password database in which the user used the same password
  • A one time only login using a computer owned (prepared) by an attacker.

What might have prevented him from setting up a backdoor?

  • The service in question may not provide a way for backdoors, for example an email inbox or common web applications
  • The privileges of the user may not have sufficient permission to install a backdoor
  • The attacker might miss the required knowledge (in the online game Stendhal most "hacks" are done by angry siblings who just want to destroy some toy)
  • The attacker might not have turned evil yet. (e. g. an employee that will be fired next month but does not suspect anything at the moment).

Why not use forced password expire?

It can be very annoying to users causing them to just add a counter at the end. This might decrease the entropy of passwords. According to my experience it generates additional support costs because people forget their new password more often than usual. I guess that is caused by the change password prompt catching them off guard while they are busy thinking about something else.

To conclude

It is far from a cure-all and it has a negative impact on usability, but it does make sense to balance that against the likelihood and impact of scenarios similar to the one I described above.

6
  • 17
    See, now what you've done is, I'd already voted up other answers, but your answer is more right, so I'm bothered that I can't upvote yours twice :).
    – AviD
    Commented Jun 22, 2011 at 15:25
  • 8
    +1 for "The attacker might have had access to another password database in which the user used the same password". This is a very real danger. If I can hack an insecure site and discover your password there, then I can access any other systems where you used the same password. Jeff Atwood has even had this happen to him before: codinghorror.com/blog/2009/05/… . Forcing password changes may lower the chances of this happening. Commented Dec 22, 2011 at 18:38
  • 2
    Why not use password expiry? See The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis. Bottom line: it adds almost no value, yet is a burden to users. Commented Jun 8, 2015 at 23:41
  • 3
    @JoshuaCarmody - "Forcing password changes may lower the chances of this happening." How can you make that statement? What empirical evidence do you have for that? The fact that Jeff Atwood had this problem merely means that he used the same password everywhere. I use all kinds of passwords online, and I don't have a 90 day rotation period, thank God. I make sure that they're 1. Reasonably complicated and 2. Different from site to site. By enforcing a 90 day policy, you ensure 1. Simple passwords that 2.share the same base with a small rotatable portion.
    – Mike S
    Commented Apr 26, 2016 at 17:14
  • 1
    What else might prevent this particular type of attack? Monitoring for unusual log-in attempts (e.g. unknown device or IP), two-factor authentication, more advanced behaviour-based monitoring. So even in this attack, password rotation is not needed. Commented Apr 3, 2017 at 21:25
93

There was a study by Microsoft concluding the password expiration policy does not increase the security in real life scenarios.

These articles were removed, but available on the Internet Archive:

Original: So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users

5
  • 2
    it should be noted, that the research paper is about web-site passwords. I think this implies that the victim is the user himself or herself. In a cooperate environment the company may suffer from an attacker instead of the individual user. Commented Jun 25, 2011 at 9:44
  • 12
    Furthermore "Rule 6 [change passwords often] will help only if the attacker waits weeks before exploiting the password" is wrong. It ignores the possibility that an attack may be ongoing for weeks without being noticed. Think of an attacker having access to the email account of someone from upper management. It is obvious that the benefit for the attacker may be larger if he keeps reading potential confidential emails instead of abusing the email account for SPAM or locking the owner out by changing the password. Commented Jun 25, 2011 at 9:49
  • 4
    Kobi is right, but one more link is the final piece of the puzzle: The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis. This shows that once an attacker has one password by the user, he can quite likely obtain another. Therefore, password expiry policies are far more burden than their value. Commented Jun 8, 2015 at 23:34
  • 3
    The UK Communications-Electronics Security Group also advises against password expiration policies: cesg.gov.uk/articles/problems-forcing-regular-password-expiry
    – Ajedi32
    Commented May 12, 2016 at 14:00
  • Above link for ESG is broken - new link here by NCSC ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry Commented May 3, 2022 at 17:55
69

We all have our opinions, but we should also be looking for actual research on the question. Besides the paper by Cormac Herley of Microsoft on website passwords noted in Suma's answer, there is a paper from ACM CCS 2010: "The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis" (pdf), written by Yinqian Zhang, Fabian Monrose and Michael Reiter. They analyzed a great dataset and did some good analysis on how effective password expiration policies really are. Their conclusion? Forcing users to change their password every six months isn't very useful:

at least 41% of passwords can be broken offline from previous passwords for the same accounts in a matter of seconds, and five online password guesses in expectation suffices to break 17% of accounts.

....our evidence suggests it may be appropriate to do away with password expiration altogether, perhaps as a concession while requiring users to invest the effort to select a significantly stronger password than they would otherwise (e.g., a much longer passphrase). ....

In the longer term, we believe our study supports the conclusion that simple password-based authentication should be abandoned outright

For research on how to help users choose stronger passwords, see Recommended policy on password complexity - IT Security

1
  • That is the same result that I got after talking to some security auditing people about the sense of ISO 270001 - especially the password-change policy. It was their opinion that frequent password changes force bad passwords. Whereas a good password does not have to be changed that frequently.
    – Nils
    Commented May 24, 2012 at 21:15
49

The only two good reasons I have heard:

  1. Window of opportunity - in an on-line attack scenario say you lockout the account for 30 minutes after 10 incorrect attempts (the Microsoft recommended setting for high security environments). Without any password expiry there is potentially an unlimited time window to attempt dictionary, brute-force, common passwords attack methods. Password expiry caps that. In an off-line scenario, where you do not realize your passwords have been stolen, again expiring passwords provides the attacker limited window of time to crack the passwords before they become useless. Of course as @graham-lee states you need other controls in place to detect things like a back-door

  2. Compliance - virtually every regulator and auditor will look for password expiry. Including PCI-DSS, HIPAA, SOX, Basel II, etc. Correctly or incorrectly this is the world we live in. In addition the "no one got fired for buying IBM theory". If you do not have password expiry and others in your industry do, if you get hacked, then you were not following "industry standard practices". More importantly senior management cannot say this to the press, to a regulator, to a court. Same reason for having state-full inspection firewalls, anti-virus, IDS even though they are less effective now than 10 years ago.

That said as everyone has said password change is terrible for user experience, especially where there is no or limited single sign-on it can lead to "password change day" where a user goes through and changes the password for their 30 systems to the same one usually by incrementing a digit. This is clearly not desired behavior. My recommendation for changing this culture if it is possible in your regulatory / audit environment is to change your policy to remove password expiry with a clear justification (plenty here). Get this approved by the appropriate security governance and reviewed by audit / regulator. Then go ahead and change the systems. Alternatively use more single sign-on and federated ID, ideally with two factor, so that at least users only need to change one or a few passwords.

9
  • 6
    "Compliance" includes "compliance with regulations which will cause industry regulators to fine your company substantial money for incomplainace". IIRC, password rotation is a mandatory part of PCI compliance, among others.
    – dannysauer
    Commented Jun 22, 2011 at 22:51
  • 23
    Alas, "compliance" essentially means "clueless cargo-cult monkeys armed with checklists" these days. It is unfortunate that noncompliance will have other impacts, but that's irrelevant to security. Commented Jun 23, 2011 at 11:19
  • 4
    @Rakkhi: Yes, yes, I'm not saying it's irrelevant to everything, it's definitely relevant to the bottom line - but so is everything else a company does. It's security theatre, not actual security (not sure if that's within the scope of this question though). Commented Jun 23, 2011 at 11:57
  • 12
    @Rakkhi: Of course it is a multi-billion dollar business; selling snake oil and miracle cure-alls has been profitable throughout human history. Profitability != utility. Commented Jun 23, 2011 at 13:27
  • 1
    HIPAA at least does not require password expiration. It requires "Password management (Addressable). Procedures for creating, changing, and safeguarding passwords." law.cornell.edu/cfr/text/45/164.308 (a.5.ii.D) Commented Apr 3, 2017 at 21:34
34

One reason not mentioned here, is that it prevents people who use the same password for everything from getting your system compromised if their password is figured out somewhere else. After a few passwords expire, users will start to have to come up with original passwords, which means when their favourite password is stolen and all their emails, social networking sites, and personal accounts get hacked, your system will still be secure.

21
  • 71
    users will start to have to come up with original passwords. This sounds like wishful thinking to me. Most users are likely to 'game' the system using sequentially increasing suffixes or similar, or pingponging between two passwords. (Please don't suggest that you store every password that the user has ever used...)
    – Roddy
    Commented Jun 22, 2011 at 20:02
  • 5
    @Roddy: I've used one system that stored my last ten passwords, but unfortunately it was possible to use sequential suffixes. Commented Jun 22, 2011 at 20:51
  • 19
    How does forcing you to change you password on system A prevent you from changing the password on system B to match the new password on system A? Now the user changes their password on both systems every 90 days but the passwords stay in sync.
    – this.josh
    Commented Jun 23, 2011 at 6:20
  • 7
    Haha, I think if my company were that strict, it would be a formula for 1: Never logging out, 2: Everyone having a convenient sticky with their current password stuck to their monitor. Super Secure!
    – Alain
    Commented Jun 23, 2011 at 16:19
  • 9
    @Chad: That's not a "good algorithm", that's a security vulnerability. In order to enforce those checks, the passwords must be stored using reversible encryption (if they're even encrypted at all). No one who understands security stores passwords in a way that allows recovery of the plaintext, or even a list of characters in the password.
    – Ben Voigt
    Commented Jul 2, 2011 at 14:27
31

How much will an expiration of passwords improve security?

diagram of relation time:vulnerability, depending on passwort change or not This image shows, for some scenarios, the relation between time and the probability, that a brute force attack on a type of password succeeded, depending on the regular change of the password. The absolute timespan is of minor interest. How long it is - either there is not much difference, or the vulnerability is already pretty high.

As mentioned from others before, there are different scenarios, where changing the password might help:

  • a) User A tells a coworker B his password in a special situation. Later B is fired. He now might think about misusing the password of A (his own account is deleted, we assume), but it could need some time (losing a dispute against the company in court, for example) before starting his attack. Here, it is very useful, to change the password - but of course not from secret2010 to secret2011.
  • b) Attacker has access to the shadow file, and is brute forcing with certain amount of CPU-power (or GPU).

In the case b), the policy to change the password, looks reasonable, but you do only profit, if the risk to be vulnerable is already really high. Let me explain it with numbers:

Assume an attacker might try 250 000 passwords per second. Assume you say the password expires after 183 days, (about 6 months). The password is generated from a-zA-Z0-9 which is 62 signs. Assume the password is 8 signs long. Check how probable is a breakin after 10 year, which is 20 change intervals.

I've written a program, to test different parameters; call the program with

java PasswordCrackProb 8 62 250000 s 183 20

len             = 8
signs           = 62
attacks per day = 21 600 000 000
change after days= 183
intervals       = 20    days = 3660 years = 10
M               = 218 340 105 584 896
attacks         = 79 056 000 000 000
p(cracked)      = 0,3620773 without change
p(cracked)      = 0,3060774 with change

The result means, that it is cracked with 36% chance if the password wasn't changed, and with 31% if it was changed (but the attacker has a fresh shadow file). The difference is significant, and more so, if we take a longer time, 40 intervals, like 20 years:

p(cracked)      = 0,7241546 without change
p(cracked)      = 0,5184715 with change

but while 52% is much lower than 72%, 52% might not be acceptable.
But if we look at smaller intervals, the relative difference between changed and unchanged passwords gets smaller and smaller.

p(cracked)      = 0,0905193 without change
p(cracked)      = 0,0873006 with change

If you assume more CPU power or weaker passwords, the crack time gets smaller, of course, but the number of attacks per day is not very interesting. We have to assume: We can not enforce the user to change the password on a daily basis. So some days - maybe a week - is the minimum. And we don't need a maximum for longer than 20 years. Systems change, people change jobs. You cannot avoid to change the password after 20 years.

If the attacker has too much power, and brute forces the whole namespace in a single day, a weekly change won't help you much - he always wins. And if the attacker can only brute force 1% of the namespace (for a given password length) in 50 years, it doesn't help as well, to change the password - you will (nearly) always win.

Only in an intermediate, balanced scenario, the password change could make a difference, but do you really know, whether the bad guy needs 1, 10 or 100 years to brute force your password?

But keep in mind: If the attacker only once had access to your shadow file, which is now expired, the comparison from my program doesn't fit.

6
  • 4
    I like this answer, however I am amused that your graph goes up to 120% likelihood :-)
    – Rory Alsop
    Commented Sep 15, 2011 at 10:56
  • 3
    A dot on the frame can easily be overseen. Since there is no dot on the 120% level, there is nothing directly wrong with it, and OpenOffice displayed the 120% by default. Using the graph without further graphic manipulation was just a fast solution. Commented Sep 15, 2011 at 15:29
  • 3
    LOL - it was purely the labelling that amused me. I think the graph does a good job of providing visual indications of that increasing gap over time.
    – Rory Alsop
    Commented Sep 15, 2011 at 15:54
  • 1
    Yes, but only worth mentioning, when the insecurity is already at about 40% or higher. Commented Sep 15, 2011 at 16:58
  • Very interesting. Note that the curves are almost the same in the lower part of the plot - where you should hope to be.
    – Calimo
    Commented May 8, 2014 at 11:40
25

Simple answer - these days it almost never helps. Previous answers give the main two scenarios where it will, but even then, 90 days is still not that useful.

It could be worse - we spent ages persuading people that 30 days was too short but back in the day when stealing the SAM was relatively easy folks were very worried about a brute force attack on the SAM. We got many companies to agree on a compromise of 90 days but although cracking power has definitely gone up, hashes are better protected and generally most places now have at least some password complexity rules in place so it has become far less important.

4
  • alsop has your thinking on this been affected all by the large number of recent breeches? e.g MTGOX whole database being dumped. I have definitely upped my likelihood rating on off-line password crack in my attack trees. Even with basic complexity amazing how many set Password1 etc
    – Rakkhi
    Commented Jun 23, 2011 at 9:16
  • 1
    @Rakkhi - I tend to rely on the wondrous powers of longer passphrases:-) I do agree though that the database dumps are an issue for those who use simple/short passwords.
    – Rory Alsop
    Commented Jun 23, 2011 at 9:20
  • alsop don't know any organization that sets a 12 char or 14 char min password length though
    – Rakkhi
    Commented Jun 23, 2011 at 9:22
  • @Rakkhi - I know. <sigh> We just need to keep hammering away at them.
    – Rory Alsop
    Commented Jun 23, 2011 at 9:26
17

I would just like to add one thing. We can approach to this problem from social angle. By reseting password every X days we are telling the user - Hey, this is important and it should not be taken lightly!

2
  • 1
    This is actually a very important point, that is often overlooked. The problem is finding the balance between "changing passwords very 30 days is plain STOOPID, lets just post our passwords everywhere", and "hrmm, password? Yeah, I think I got one of those thingies a few years ago, when I joined the company... it's probably written on my employment form...". Intuitively, I would guess between 6 months to a year is often enough to remind the user of the password sensitivity, but not too often to really bug users. But yes - social aspects have a bigger impact on security than is often considered
    – AviD
    Commented Jul 5, 2011 at 0:33
  • 9
    It tells me as a user that it is not important, e.g. the IT department have not read the research papers. Commented Apr 25, 2014 at 16:21
16

As one of the new things in the new NIST publication, called Special Publication 800-63-3:

No more expiration without reason. [...] If we want users to comply and choose long, hard-to-guess passwords, we shouldn’t make them change those passwords unnecessarily.

From: https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

The publication from NIST itself can be found here: https://github.com/usnistgov/800-63-3

It has some other recommendations that the infosec world has long accepted: 8 characters minimum, a maximum length of 64 characters or longer, no password hints or secret questions, allow all characters (including emoji), and no annoying rules like "must contain a special character but not a dollar or percent sign".

1
10

Most online services (e.g. Banks) limit the number of online attempts per time unit, rendering a brute force attack futile.

The result of a password-change policy is almost always a security risk. It can take the form of a PostIt password, or passwords that take the form pass!1000, changed to pass!1001, then to pass!1002 and so on.

10

To add to what has already been said, I can think of 2 more reasons why changing passwords regularly is helpful:

1) When computational power raises substantially

Say, in early 90s 7-char passwords were considered secure because computers weren't nearly powerful enough to bruteforce them.

24 years later systems which still have the same password can be successfully bruteforced.

Some calculations, considering the password consists of 24 letters (uppercase and lowercase), 10 numbers and 10 symbols, and Moore's law (x2 more power every 2 years):

possible combinations = (24 + 24 + 10 + 10) ^ 7 = 6,722,988,818,432

tries per second in 1990 = 100,000 (for example)

time required in 1990 = possible combinations / tries per second = 2 years

tries per second in 2014 = tries per second in 1990 * (2 ^ 12) = 409,600,000

time required in 2014 = possible combinations / tries per second = 4 hours

This is more about increasing minimum required password length, but it should be done regularly and short passwords should be changed.

2) Compliance with ISO/IEC 27001/27002 standards

From ISO/IEC 27002:2013, section 9.4.3:

A password management system should:

...

e) enforce regular password changes and as needed;

3) Compliance with PCI DSS standard

From PCI DSS v3, section 8.2.4:

8.2.4 Change user passwords/passphrases at least every 90 days.

8.2.4.a For a sample of system components, inspect system configuration settings to verify that user password parameters are set to require users to change passwords at least every 90 days.

8.2.4.b Additional testing procedure for service providers: Review internal processes and customer/user documentation to verify that:

  • Non-consumer user passwords are required to change periodically; and

  • Non-consumer users are given guidance as to when, and under what circumstances, passwords must change.

Passwords/phrases that are valid for a long time without a change provide malicious individuals with more time to work on breaking the password/phrase.

4
  • @PhilippeCarriere There are multiple versions versions of ISO/IEC 27001. I was referencing the latest 2013 standard. There is also an older 2005 standard, which is probably what you are looking at. Commented Jul 28, 2015 at 5:41
  • @PhilippeCarriere Ah yes, sorry, I meant ISO/IEC 27002:2013. It contains more detailed instructions than 27001, which is more of an abstract overview. Commented Jul 29, 2015 at 6:07
  • +1 for the Compliance with ISO/IEC 27002:2013 standard. Commented Jul 29, 2015 at 14:46
  • 1
    Research has indicated that changing passwords is not all that helpful. However, the only reason for some companies to do it is to be compliant with some standard. PCI DSS standards, ISO, and even FDA...
    – Bobort
    Commented Nov 7, 2016 at 16:59
9

A major consideration to take into account when questioning this is that you may not know your account has already been breached.

If your password had become compromised, and you were aware of it, you would obviously move immediately to change it in any case.

By forcing you to change your password every 90 days (or face account suspension) administrators are mitigating two risks. 1. That inactive users/accounts will be available for unlimited amounts of time for an attacker to try and brute-force their way into. 2. That, in the event you do not you've been breached, you are forced to change your password regardless (thus re'locking' the attacker out of your account)

2
  • 7
    1) For inactive accounts, why not disable the account after 90 days of innactivity? It should be easy to tell if the account is not being used. 2) Whats the best case for locking out an attacker? reduction of access to hours, minutes? How long does it take an attacker to acquire value from the compromised account?
    – this.josh
    Commented Jun 23, 2011 at 6:23
  • 1
    There are way too many scenarios to get into, and it's impossible to speak of all of them, but needless to say it is not useful/necessary to have password changes in ALL cases.. that being said, it does have use in some cases.
    – DKGasser
    Commented Jun 23, 2011 at 11:13
9

It might seem somehow better in sense that the institution is enforcing to change passwords at some periodic interval. However, if the user is changing the passwords in the interval, but is always leaving a patter behind his changes, then it makes no sense of changing the passwords. Its more serious threat instead. The user feels he/she has changed his/her last passwords and feels safe. and the attacker is always getting a clue to the password.

-

The best way is always to suggest the service provider to implement a better and safer algorithm then asking for its end users to reset the goddamn password every time. If someone is same enough he/she will have in mind that these days we have Single Sign On, and OpenID, where people prefer to login with one accounts rather than remembering different passwords for different websites.

- Despite of all the discussions, its recommended to change your password frequently, But,

On YOUR FREE WILL

A Quick Tip : Use multiple words in your password (The safest marked till date).

8

We rotate 'public passwords' (guest wifi) to flush out access of employee's who have since left the company.

We accept the burdens of rotating 'individual passwords', because a) we always start with the assumption that every non-techie's accounts have already been hacked. And b) to 'automatically close' all accounts which have been forgotten. Since the 'centralized set new password' access is the only one we never forget to close. (fail-safe expiry of all single sign-on dependencies) This also includes hardware (notebooks) that are handed to a new owner, and might have 'saved passwords'.

(c) Plus, it makes people stay aware of where their passwords are auto-saved.)

(d) Plus, we can tell people to 'please change all your passwords', after a questionable data-loss. That only works reliably with employees who have been trained at password-changing.)

In short, automatic expiry is a safe-guard against people not behaving as you asked them to do.

7

Many answers already indicate that often forcing users to change their passwords isn't useful; I would like to add the opinion of Bruce Schneier, probably the most famous security expert.

Basically he says that it depends on what that password is protecting, and how a stolen password can be used. This sounds obvious, but it is not obvious at all that between the password for Facebook and the one for your online banking, it would be better to change the former. That's right: it makes more sense to change your Facebook password rather than your bank's password. Let's see why.

Regularly changing your password helps in case someone has found it and you are still unaware of it, because the attacker prefers to be stealthy. Depending on the account they have violated, that may, or may not, make sense.

  • In many cases, if the attacker discovers your password, he'll do something that you will surely notice. For example, if he can access your bank account, he'll transfer money out of it. Quoting Bruce: "In this case, it doesn't make a lot of sense to change your password regularly -- but it's vital to change it immediately after the fraud occurs." The idea is that if no one is stealing money from your account, it most likely means no one has found your password (why would they wait, otherwise?), so there's no reason to change it.

  • Instead, someone who steals your Facebook password might use it to spy on you. For example, your wife might use it to check whether you have a lover. In this case you are not going to notice the attack, because the attacker wants to be able to continue spying on you, so they are not going to post new messages or anything that would be noticeable. Here, regularly changing your password would prevent her from continuing.

So, given the different attack scenarios, changing your Facebook password is more useful than changing your bank's password. It is quite counter-intuitive, but it makes sense.

5
  • +1 except for the last sentence. If it makes sense, then it's not, by definition, counterintuitive. Commented Mar 11, 2017 at 0:28
  • @DanHenderson: No, it’s not. Intuition means immediate cognition without the use of conscious rational processes, it’s not about making sense.
    – Wrzlprmft
    Commented Dec 1, 2023 at 22:12
  • @Wrzlprmft counterintuitive: "contrary to an intuitive belief or to common-sense expectations" Collins Dictionary; "different from what you would expect : not agreeing with what seems right or natural" Britannica Dictionary; "Contrary to intuition or common sense" Wiktionary; I don't see how any of these definitions can describe something that makes sense. Commented Jan 23 at 19:13
  • And just for fun: to make sense means to be sensible, coherent, reasonable. See also insensible definitions 3 & 4, incoherent, and unreasonable definition 2. Commented Jan 23 at 19:23
  • @DanHenderson: I don't see how any of these definitions can describe something that makes sense. – I am not claiming that counterintutive implies that something makes sense; I am claiming that something can be counterintuitive and make sense at the same time (and usually you would only use counterintuitive in that case, even though that it’s not its meaning). For example, to many it is counterintuitive that harmonic series diverges, although this is uncontested, and to many this makes sense after they sufficiently engaged with the pertaining mathematics (and thus went beyond intuition).
    – Wrzlprmft
    Commented Jan 23 at 20:18
6

A strict literal reading of the question leads to the answer: It increase security in a negative way: either through post-it notes or using increasing numbers or shift-number.

It might decrease the risk of legal issues from compliance, however.

4

Lost, misplaced or stolen hardware can also be an attack vector providing access to at best obfuscated passwords.

Attacker can steal a smartphone and recover passwords to WiFi -- in most places the general user account.

2
  • If the user notices something stolen then he should immediately change the password if he cares about security. Regular password changes (few months) aren't relevant in this case. Commented Jun 22, 2014 at 21:12
  • @user2529583: problem is, users in general don't care for security. It's a burden for them - something many of them consider to be established by nerds just to torment them. Commented Jan 24, 2015 at 13:46
4

I would tend to agree that this is primarily a compliance-driven requirement with at best a marginal net increase in security (at, unfortunately, a substantial cost in loss of operational availability, due to otherwise legitimate users being locked out after 90 days, machine-to-machine communications failing because their passwords expired and nobody updated them, calls to the Help Desk to resolve password reset problems and so on).

That having been said, there are valid reasons for enforcing such a policy (although -- these justifications are greatly lessened by the relatively lengthy validity period for a particular password... after all if a cyber-crook gets your password for 90 days, there is a lot of damage that he or she can do).

The biggest advantage comes in the following scenario :

  1. You get hacked or otherwise compromised, and the cyber-crook finds out your username and password.

  2. It happens to be near the "change threshold" time period (typically -- the end of the quarter, and don't think cyber-crooks don't know that).

  3. You are required to change your "old" password (which both you and the cyber-crook, know).

  4. You follow Company policy and change your password, meaning that now the cyber-crook is locked out again. He or she can try to use the same methods as before, to get unauthorized access to this credential as well...but doing so may be annoying and time-consuming.

The point here is, "changing one's password to something new", is not something that a cyber-criminal will normally do, because from his or her point of view (unless, of course, the password hijack is really a kind of Denial-of-Service attack), changing the password and locking the legitimate (original) owner out of the account, will immediately alert the legitimate user that something untoward, is going on.

This is on top of the fact that cyber-criminals usually hijack thousands of passwords at a time; changing all of these, particularly because they may not have access to the back-end systems set up to allow legitimate users to do this, can be an onerous task.

None of the above is written ignoring the fact that cyber-crooks will usually set up their own, privileged account, the moment that they get unauthorized access to your system, or is meant to ignore the other potential weaknesses in the "mandatory 90-day password change" paradigm that is so prevalent these days. Think of this rule as one (minor) element in your layered defense strategy, and you'll see that it has a place... but it's certainly not something that you should rely on, to keep the bad guys out.

4

I personally don't think that enforcing password expiration on office users (or, people hardly familiar with computer use, let alone cyber security) is a good idea in the form as it is done in many organizations. As it was noted above, the major security flaw in this case is that those same office users simply write their passwords on sticky notes and paste them to their screens or stick them in their desks. Or, if the person is slightly more "advanced", they may start using passwords such as letmeinMONTHYEAR.

Nonetheless, periodic password expiration is a good thing, once it's coupled with the proper password management. Obviously most (non-savant) people will not be able to remember really secure passwords -- something like v^i77u*UNoMTYPGAm$. So what shall we do?

I personally use a password manager that tracks all of my passwords, except one, the master password. This really simplifies things and makes them way more secure (provided my master password is secure itself and I can easily recount it to log in to the password manager.) There're several commercial password managers, which I will let you discover and test for yourselves. I personally use Lastpass which is free for general use and is secure. It is available via the web browser and can be also installed as an app on your smartphone or tablet. As for security concerns of letting a third-party solution manage all of your passwords, I rely on the vetting done by Steve Gibson. You can watch the full version of it here.

3
  • 1
    I rely on the vetting done by Steve Gibson Oh boy
    – forest
    Commented Mar 16, 2018 at 6:54
  • @forest, do you have some substantive criticism here? For real people security is a trade-off between many different things. The time to properly evaluate the security of such a tool is one of the many things that simply isn't worth the investment for most people, because their risk of password compromise via the tool is so low that the many hours required to do a thorough vetting are wasted. Even for security experts, have you validated the code of your OS, your browser, and every piece of software on your machine that touches your passwords? What about your drivers?
    – Paul
    Commented Mar 19, 2018 at 14:59
  • @Paul I have "validated" much of the code on my OS, including the drivers. I have not validated the browser (honestly, both Firefox and Chromium code makes my eyes bleed) because all that is needed is a kernel that is capable of maintaining a security policy around the browser. That is what the TCB is.
    – forest
    Commented Mar 20, 2018 at 2:24
4

When your users are humans, it doesn't necessarily increase security.
See the FTC post "Time to rethink mandatory password changes" by Chief Technologist Lorrie Cranor, based on research about how humans actually use these systems. (Washington Post coverage here.)

Also, as discussed in the SANS security blog, "One of the key guidelines of changing behavior is [to] focus on the fewest behaviors that address the greatest risk." The costs of requiring the password changes are better spent on teaching users to use strong, unique passwords and/or password managers/multifactor authentication. Additionally, the benefits of password changes have declined now that attacks can and often do happen much more quickly than the long, slow, manual attacks that password changes could help cut off.

5
  • Downvote explanations? Is that not a credible source or useful information?
    – WBT
    Commented Mar 3, 2016 at 20:26
  • 1
    Link only answers are generally frowned upon - it would be better to extract the relevant parts and include them here, in case of link rot
    – Matthew
    Commented Mar 3, 2016 at 20:27
  • Seems more like cause for suggesting edits adding in what folks think are the most important parts than for burying the source.
    – WBT
    Commented Mar 3, 2016 at 20:30
  • 2
    While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.
    – Xander
    Commented Mar 3, 2016 at 20:32
  • @WBT I'm guessing here, but since you're the one who would get the rep points, I suspect people would rather make their own post referencing the same source, but extracting the key points from it, than edit your one...
    – Matthew
    Commented Mar 3, 2016 at 20:41
3

If reasonably strong passwords are used it doesn't. Passwords might need to be changed regularly if they can eventually be cracked offline if an attacker has managed to extract hashes from the database. However, enforcing password changes seems a weak form of security when users should be encouraged to select strong passwords, for example based on long passphrases.

Without being educated on password security, most users will not choose strong passwords so the 90 days change limit is designed to protect these accounts. As these users do not understand or care about the security of their account, they are likely to choose another weak password possibly based on their old one (which means an attacker can crack the old one and then use variations of that in an online attack). Using the 90 day policy in combination of checking the similarity of the new password with the old one can be seen as helping. Other users' passwords will be more difficult to crack, although if enough time is dedicated by an attacker this is entirely possible - any password with a strength of under 128 bits of entropy means that it has the possibility of it being cracked eventually, although unless an attacker is specifically interested in a particular account, this has a very low probability of occuring.

A possibly good reason for changing passwords is that users will often save passwords in insecure places. For example, the browser autocomplete functionality may have remembered the password on a friend's computer. However, this is neither here nor there.

This is why it is seen as good practise to change them every so often. The 90 days caters for the lowest common denominator. Any users using strong passwords generated using a password generator will have minimal hassle for them to then change theirs so this policy should not cause significant problems. I can understand users with many accounts with this policy will be annoyed.

A further reason for changing your password often is that password storage algorithms such as bcrypt and other key derivation functions have an iteration count, that can be upped to increase the work factor as Moore's Law takes hold. Entering a new password gives opportunity for the password hash to be resaved with more iterations, or that the entire hashing algorithm be updated as the security posture of the system increases. For example, if the site was originally storing cleartext passwords, then migrated to SHA-1, then SHA-1 with salt, then eventually bcrypt, the act of changing the password often is used as an opportunity to update the stored format for this user within the database.

Note that a password change isn't technically required, just that many systems will rewrite the password to storage at this point, however they could also do this upon successful login because the cleartext password will also be available at this point. Forcing a password change will help in these instances, and also has the advantage that if there were any undiscovered password leakage vulnerabilities on the site (e.g. SQL injection) then the password will have been changed to something more secure as well as the hashing format being updated. Note that forcing a password change doesn't help update inactive accounts, which is why some standards dictate that inactive accounts are disabled after a period of time (e.g. PCI after 90 days) - if password is also stored in some format in the DB it is also recommended that this be blanked in case the user has reused it elsewhere and it is later leaked.

You must log in to answer this question.

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