Password Change Frequency

Holding users to a standard frequency of password changes is an expensive legacy security requirement. Make it longer and cut support costs without decreasing security or increasing risk.

Password change frequency rose out of a government and industrial complex need (in other words, people concerned with spies) to protect information assets from internal threats. Back in the day, computers weren’t networked, so outsiders weren’t really an issue. It was the insider that was the threat, and the only people with computers were big companies and governments. Limitations in security technology and sophistication at the time meant an idea like forced password changes every 90 days was the best solution. At the time.
And for governments and industrial complexes or anyone worried about industrial espionage or trade secret theft, it still makes sense to use password aging.
But for the rest of the business world, periodically changing passwords can be much more liberal. Like yearly. Established dogma may say otherwise, but you will never, ever hear a security penetration tester (white hat hacker) or a criminal say: “I wish they didn’t change their passwords so often”. It’s not an issue when breaking into accounts.
The fact is periodic password changes have never kept someone out of a system. Worse, forcing users to change frequently leads to poor password choice, making it easier for attackers to break in.
With modern security techniques and options, the time has come to relegate frequency of change to a choice of broad possibilities and not treat it as a mandatory security setting.
First, it won’t reveal a compromise unless that compromise is very simplistic, ie: internal user fooling around. Which is a risk, but any damage they do is very likely to occur within the frequency window regardless.
A better option is to watch for login failures. Because even if someone picks “mother” for a password, unless it’s in the hackers top 5 guesses, if you’re watching for failures, you’re going to spot the attempt. Alerting to attempts is much, much better than discovering an account is compromised 90 days after the fact.
And once a bad guy from outside gets inside, frequency changes aren’t going to stop anything they do. You need detection.
Password complexity is what aids in detection. Complexity is a factor in time, and security is about delaying the attacker until alarms go off and personnel can respond. But if other security settings like lockout and alerting are set up correctly, complexity doesn’t have to mean passwords so shockingly hard that users have no choice but to write them down. Caps, letters, and numbers are plenty strong enough to provide a window for detection.
But educating users to pick something other than Mother1 is an additional effort. The users have to be part of the solution, and the security operation needs to periodically inspect passwords as part of an overall effort.
Detection of failed attempts is the key. This allows you to pick up internal and external access attempts and deal with them before they become a compromise. And the complexity helps.
As for cost savings, doubling the password lifespan can cut help desk calls for locked accounts in half. Not a bad gain. Go from quarterly to annually and you get 4x the savings, but beware of the risk of appearing to act recklessly. If it comes up in a legal case, the other team will use it to paint you as careless, you need to be able to demonstrate that the decision was thought through.
No single security setting is the answer, though, and without additional controls and a proper risk management program, any controls in place may be worse than useless, leading to a false sense of security. Have a professional review your company’s security practices, including password change frequency.
Digital Trust, LLC

This blog and it’s contents copyright 2010 Digital Trust, LLC. Republication of this post is permitted provided it is strictly on internal corporate messaging systems; no public re-use is permitted without licensing. Any republication or reuse is forbidden if the Digital Trust name or this paragraph is removed.