Password rules: Change them every 25 years

Published: 2009-11-02
Last Updated: 2009-11-02 11:31:30 UTC
by Daniel Wesemann (Version: 1)
26 comment(s)

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.

 

Keywords: password
26 comment(s)

Comments

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?
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: http://www.gfi.com/blog/security-vs-productivity-in-the-workplace/
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.
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.
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.
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.

-ASB: http://xeesm.com/AndrewBaker
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 :)
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.

Diary Archives