How does changing your password every 90 days increase security?

  • 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.

    @Bill, thanks for this great question! We love rocking the boat and questioning "accepted wisdom"...

    It certainly makes sure that half the office has stickies with their password on their monitor or under their keyboard.

    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.

    I hate this rule and have argued against it a lot. for more details (in a comment for 0 rep)

    @johnfx, definitely. And how many allow exemptions for C-level (especially CIO) and directors (especially director of IT) who demand not to have expiring passwords.

    Obviously changing the password every day is impractical. If you graph the impracticalness vs number of days, and the increase in security vs number of days on the same graph, the lines always cross at 90 days, so 90 days is optimal :)

    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.

    I interviewed the IT-manager at an organization, and he said when the relaxed their password policy, the yellow notes started to disappear.

    Yahoo is doing away with passwords, going password free. I think this is a better idea. They text you a password that is only "good" for 5 minutes, or X amount of time, but you get to keep you authentication cookie. So it's like changing your password every time you login.

    Would like to add ,Users are not careful enough with their passwords while creating accounts on other sites , So for example A has thought of a new password X for his banking transaction , in a months time he might make many more accounts on lot less secure sites ( which does not use HTTPS/SECURE HASHING/... ) where he might use the same password which makes him vulnerable to another attack vector . Making "time out" password a good strategy.

  • Justin Cave

    Justin Cave Correct answer

    9 years ago

    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.

    This is assuming a shadow password file exists. Many OS's don't have such a beast.

    @david - Very true, the shadow password file is a Unix-ism. Most systems store password hashes somewhere, creating the potential for someone to acquire the hash, break the hash offline, and then use the cracked password to compromise the system.

    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 - 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.

    @Marcin: are you still using MD5 for hashing your password? If so, then you have a different problem.

    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.

    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.

    But... if you can get the backup, then you often don't need the passwords! You need the passwords for an up-to-date view of the content of the computer, but for many means, the older version is sufficient!

    Of course the 6 month backup is next to useless if noone can remember the password they used 6 months ago - or was it the password from 8 months ago...

    @JustinCave take a look at this, does 15 BILLION per second of SHA1 sound slow to you? MD5 is 45B/sec so SHA1 not that much slower either. The point is that we really have to rethink our 'what is an average attacker capable of' approach. In 90 days this setup (single computer, 8 beefy video cards, so not cheap, but not out of range of a single person), it can crack 1.2*10^18 SHA1 combos. That's almost all of all upper, lower, and digits up 10 char passwords.

    @marcin You seem to misunderstand what @Justin is saying. Anyone who is using non-iterated password hashing algorithms is over 30 years out-of-date. Unix did 25 iterations even back in 1978. Good algorithms use e.g. 10000 iterations these days, and try to prevent the user from choosing passwords that are easy to crack. See How to securely hash passwords? - IT Security - Stack Exchange

    I think that a more plausible attack is not "someone acquired the shadow file and reversed the hashes", but "someone acquired the note from the CEO's trash and read his login credential". If the CEO will not change his password, the garbage man could log in a year after he found the note.

    @nealmcb: That just means you raised the cost or time of the attack. 10k iterations means a linear increase in cost/time. With elastic clouds it costs the same (approx) to use 1k systems and run them in less time. Not cheap with 10k, but it depends on the dollar value of the data.

    100,000? sha-1 is ~7.5 million iterations a second on a single GPU, 100,000 or less seems a little low.

    @ewanm89: actually SHA-1 is even faster than that. On a somewhat old GPU (Nvidia 9800 GTX+, bought for about 100$ two years ago), I can do 160 millions SHA-1 per second. Even a 2.4 GHz Core2 quad can do 48 millions SHA-1 per second (using SSE2 instructions).

    @Thomas Pornin: I should rerun my benchmarks on my GTX-265 and 2.67 GHz Core2Quad then.

    `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)

    The "90 days" is a sign that this policy was dreamed-up by a security "fan" rather than a security professional. Why N days? Is there any empirical reason for it? Has anyone implementing one of these policies actually researched what the value of N should be in order to be effective? Nope.

    Please see comments by Kobi and Jan28 below. If you take into account research such as The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis, then we see practically no value from password expiry policies. I have yet to see anyone who argues for password reset policies acknowledge this research.

    @TheGreatContini Right on. +1 to your comment, -1 to this answer. There's a lot of conjecture here: "organizations as a whole tend to be more lax about backups" ... are you kidding me!? Do you work with a bunch of incompetents? Getting access to backups is like getting access to the computer itself! Corporate data is in there! Of course organizations protect their backups. At least, mine do! ... Just one example of a fallacy presented by this answer. -Infinity, if I could.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM