Threat Level: green Handler on Duty: Jan Kopriva

SANS ISC: Password rules: Change them every 25 years - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Password rules: Change them every 25 years

While there certainly are parts of the password rules - like length, complex syntax, special characters, etc - that indeed may contribute to improving password security, the often stated requirement to change passwords every 90 days has far less obvious benefits.

There are four basic ways for a bad guy to get your password:
(a) Ask for it. So-called "Phishing" and "Social Engineering" attacks still work, and always will
(b) Try dictionary words at the login prompt in the hope to get lucky ("Brute Force")
(c) Obtain the encryped/hashed password somehow, and crack it
(d) Leech the password off your computer with keylogger malware

None of these four scenarios becomes less likely if you change your password every 90 days. If the bad guy can't break the password hash (c) within a couple days, he'll likely just look for an easier target. Attack (b) is also out for quick wins - either it works within the first couple dozen passwords tried, or the bad guy moves on to easier prey. If (b) or (c) are successful, or the attacker already has the password through (a) or (d), 45 days on average is more than enough to empty out your bank account or use your email address for a big spam run.

The concept of password expiry remained the same for the last 25 years or so. Infosec professionals, auditors, PCI, ISO27002, COBIT, etc all keep requiring it, unchanged, even though the threats have changed quite a bit. Forcing a user who had a weak password to change it will just make him pick another weak one. Forcing a user who had a very strong password to change it will eventually annoy the user into using simpler passwords.

So what gives? There is one practical benefit. If someone has your password, and all they want is to read your email and remain undetected, they can do so forever, unless you eventually change your sign-in secret. Thus, regularly changing the password doesn't help much against someone breaking in and making it off with your goods, but it DOES give you a chance to shake off any stalkers or snoopers you might have accessing your account. Yes, this is good. But whether this benefit alone is worth the hassle and mentioned disadvantages of forcing users to change their password every 90 days, I have my doubts.

Infosec risk management is about identifying threats and vulnerabilities, and then picking a countermeasure. But if the chosen countermeasure doesn't in fact make the identified threats less likely, all we do is play security theater, and the countermeasure is one that we don't need.

Unless, of course, "best practice standards" and audits force us to have it.



385 Posts
ISC Handler
Nov 2nd 2009
The last line in your entry hits the problem right on the head. Unfortunately most auditors we encounter have no clue on the **why**s of what they are requiring.

What do you recommend we do in these situations?

1 Posts
My thoughts exactly. Just last week I wrote an article on more or less the same topic. Hope that a day will come when the people responsible stop following "best practices" blindly.

Link to my article:
1 Posts
I introduced the "change your password every 90 days" rule in a fortune 500 company and I will explain why. Many people use the same password on multiple systems. I discovered that one of our systems allowed users to view the password hashes in its name directory (as a "hidden" field) so I investigated the hashing algorithm it used and found that the default was the weaker of the two that shipped with the product. We quickly changed that after I verified that cracking of that hash was possible (by brute force with a modified "John the Ripper"). We then introduced the 90 day rule to ensure that there is a continual clean up of password hashes as we improve password hash security across all of our systems. It also discouraged people from using the same password on external web sites as they used on company systems.
5 Posts
Mitigation of the attack doesn't change it's probability of occurrence, instead, it changes its probability of success. You've made two assumptions: 1) all password thieves will give up after a few tries in the case of brute-force attack, and 2) all thieves will give up after a few tries in the case of dictionary attacks. Maybe this is the case, generally, but not always - it depends on the specific adversary. You're implication that we (auditors) are blind to the changing threat scape is simply not always true - every 90 days is still too long given today's processing power. You have to take length, complexity, history, and the various account lockout policies into consideration when looking at password lifetime. These controls, along with the supporting audit-related controls, work in concert to provide the best possible protection for a given system.
1 Posts
I always considered password change interval to be related to the processor power of the day. The time it takes to crack hashes and produce rainbow tables decreases with processing power increases. Moore's law can be used in describing this effect to help understanding. I start be calculating the password space in relation to the complexity rules in effect. I then use benchmarks of cracking tools and external research to arrive at a realistic password per second cracking rate for the hash in question. Then in order to determine the number of days for changes, an acceptable percentage of password space being cracked over the time period is selected.

It's an eye opener to some that even a "strong" password can fall in seconds if it is the first generated by the password cracking tool.
G.Scott H.

48 Posts
I suppose dictionary attacks only work, if an account is allowed 22K attempts per minute ? (or am I missing something else ?)
Frequent password changes do not significantly add to security unless the changes are performed more regularly than the attacks can be generated (very unlikely).

If we were regularly using robust, multi-factor authentication for the majority of our logons, we wouldn't be so focused on frequent password changes.

This post hits the issue on the head, and I've stepped in this minefield recently at my employer. But it's hard to win the argument without any citations.

Are there any studies to support the assertion that forced rotation actually leads to weaker passwords? Seems obvious to me, but that's just 'anecdata'. :)
As my diary post and also various comments above state, there are certainly threats against which frequent change of the password DOES help. But the measure should always match and mitigate an identified threat, and not be applied blindly "because it is best practice". Just as you shouldn't use this diary post to blindly decide that you do NOT need a password expiration :)

385 Posts
ISC Handler
One of the reasons for frequent password changes is to compensate for weak controls on closing user accounts. Many organizations have trouble closing user accounts on all systems soon after a user is de-authorized. For example, if an organization is good at shutting down VPN accounts quickly, but bad at dropping database accounts, then in 90 days the database account will expire, but the unauthorized user won't have an easy time renewing the account.

What I can't understand is the trend to more frequent password change requirements. 10 years ago, annual password changes were sufficient on many systems. Until recently, 90 days was the standard. Now I'm seeing 60 days, and expect 30 days very soon.

I've never gotten an explanation of what vulnerabilities are present in, e.g. days 61-90 that weren't there on days 1-60. We're just forced to implement shorter password changes. I know from spot checks that shortening password change intervals drives more users to put passwords under keyboards, etc.

Crackers have broken systems which use tokens that change passwords every 5 minutes, using keyboard sniffers and real-time monitoring and exploits. We'll never get password change intervals short enough to mitigate those attacks.

We've gone past the point of diminishing returns on short password change intervals. We should focus on improving controls in other areas, and augmenting or replacing usernames/passwords for authentication.
8 Posts
In addition to weak controls, with any sizeable user population you have a problem with a large number of users re-using passwords. People will re-use passwords at work, on websites, at their banking institution, etc. So, all it takes is for one of these accounts to be compromised and the password goes into the database.

So, we continue to recommend better password techniques - here's a video:

Michael Argast, Security Analyst, Sophos
1 Posts
Passwords are always a weak issue. No matter what you do these passwords are being created by people who are not thinking about what someone might guess. They are creating them so they can remember them, which means a decent Facebook profile may allow the intruder a simple path to guessing it.

What organizations fail to do is log failed attempts, and then act as a security team on them.

Also, limiting where you can log in from is a good approach. For instance, if your end-user has static a IP, USE IT as a requirement! If you know your users only come from one range, lock it in so 99% of the world is not in your accepted logins range and use what you know is acceptable. It is more about what you do than what the end-user does.


To truly tighten access goes beyond the end-user!
Al of Your Data Center

80 Posts
> every 90 days is still too long given today's processing power

Adam, I disagree. I do not have the greatest processer, but I can dictionary a hash at over 30,000 per second, and brute force almost that. Without a dictionary, assuming 6 characters with mixed upper case, lower case and numbers, I can crack the aformentioned in 50 hours or less.

Given that I am using my CPU and could greatly increase my cracking performance if I used my GPU, what would you suggest is a good password change age? Keep in mind, the lower the age, the more sticky notes next to the monitor and under the keyboards with their entire password list, which I believe is a much greater risk, because it is far more common.

Password experation should no longer be based on CPU/GPU brute force, which is why I believe 90 days is far to short a time. Between 180 days to never is more appropriate. This is all assuming proper account management such as disabling all terminated accounts.

Al of Your Data Center
2 Posts
Bad math. That should have been 22 days for brute forcing. It is closer to a week if using a dictionary in combo with the brute force.
Al of Your Data Center
2 Posts
I don't think requiring password changes helps any with the password reuse problem. Anecdotally it seems to just cause people to cycle through the same group of two or three passwords they use everywhere.
This is another pet peeve of mine. Many sites require password complexity to a degree that nobody can remember the password. This is what leads to people using sticky notes on their monitors with the password, which is exactly the opposite of what the original intent of the complex passwords really was.

In a sense it matters a lot what website you are trying to protect. For online banking, some degree of complexity can make sense. For a forum where you post pictures of your cat, probably not so much.

I would be interested in seeing a discussion of the advantages and weaknesses of various types of 2-factor authentication methods (eTokens, smartcards, etc). I used to think that they could solve a lot of problems, but I am starting to read stories from the field about vulnerabilities here as well. Even here, the answer could depend upon the situation - Windows supports the concept of using a smartcard for logon instead of the username/password, and this can provide some degree of security. Logging into a website has entirely different issues.


43 Posts
Fair points, but seems to miss the point entirely. What exactly are you trying to protect? Complex passwords or 'password' may be acceptable depending on your risk tolerance or business needs. I'm not advocating either, but the arguments presenter here may make sense for some situation and be completly out of what in another.

I also don't' get the auditor 'gutshot' at the end of your piece. An auditor's role is to test the controls you have put in place, so while it can certainly be a pain to have someone poking around a system or network, they are only doing what you have stated is in place. If you have executive sign off that disagrees with there finding, as long as you are doing it there is no issue.

1 Posts
Users sometimes shares passwords. This is one thing a password change requirement will help limit.

I agree that forced password change, even with history might result in users picking weaker passwords, but then teach them good password generation methods, of give them tools. I personally now use 1Password on my Mac and my iPhone, and use generated passwords almost everywhere.

A password on a post-in note can not be retrieved by a remote hacker. It requires somebody trusted enough to get access to the users workspace.

So in most cases, running a cracker on the password hashes a couple times per year, and force the owners of the weak passwords to change it would be a good idea. Many users uses default passwords. And if you have 5000 users, at least 100 of them have the same password, and 50 have the 2nd most popular. It is always easy to crack some passwords.

The important thing is to train the important users. Or give them the tools
Povl H.

79 Posts
One problem is security systems which force complex rules on you and you don't know what the rules are. The message is too generic. Am I aupposed to have a digit, special character or uppercase letter or all three? And what is the minimum length?

Now another problem is that I much prefer to use pass phrases which are three or five words in length. With those I don't need a digit, special character or whatever. But no, I gotta put in the useless crap.

Other places limit the password length but don't tell you that they are limited. So you happily register with a 20 character KeePass generated random password and all is well. Come back a week later and you can't get in until you reset the password and shorten it to 12 characters.

And a bank only allows me 8 character password. 8 frigging characters? Unbelievable. Mind you at least that's on an https connection.

And Windows docx and xlxs files allow a maximum of 20 characters in their passwords. <sigh>
Povl H.
1 Posts
Don't know if you have seen this but this put password complexity/length in to sharp focus!

1 Posts

Sign Up for Free or Log In to start participating in the conversation!