Frequent password changes as security mythology

May 23, 2008

One of the things I see trotted out in response to potential security issues is a suggestion that we make users change their password frequently. In addition to all of the practical reasons not to do this, it's useful to ask one of the most important question in security: what risks does this protect against, and how big are they?

The concise answer is that it doesn't actually protect against any fundamental risks. What it does is limit the damage done to your systems by compromised passwords (if you are very lucky, it contains them to 'none'). And if your passwords are not getting compromised, it does nothing (except annoy users).

In other words: if your passwords are getting compromised, forcing frequent password changes is not actually solving the problem. Your real problem is that your passwords are getting compromised, and that's what you need to fix. Forcing password changes is merely a mitigation strategy, not a fundamental cure, and worse I think that it is generally an ineffective mitigation strategy.

(This feels like a terribly obvious insight now that I have actually written it out.)

Sidebar: what risks password changes protects against

Okay, I exaggerated, but not very much.

Let's start with a simpler question: what effects does someone changing their password have? (Besides causing them to write the new password down on a postit note and, if you are lucky, stick it besides their money or credit cards.)

Answer: it cuts off access to anyone else who knows their old password.

There's several risks that this protects against:

  • that their old password is compromised and hasn't been exploited yet.
  • that their old password is compromised and is being exploited, but the exploitation hasn't been detected yet.
  • that their old password will be compromised in the future using information that the attacker has already captured (the classical 'steal the hashed passwords and brute force them later' issue).

So, how big are these risks, especially when compared to the very real risks that forcing frequently password changes creates? My personal opinion is that all of these three risks are pretty low, because passwords are compromised rarely and when they are compromised they seem to be used almost immediately, usually in obvious ways.


Comments on this page:

From 75.73.34.215 at 2008-05-23 08:18:34:

And of course if your desktop is already botted & keylogged, the password change isn't going to help much.

And - Because you've got to change passwords on dozens or more accounts at 30, 60 or 90 day intervals, you have no choice but to either write them all down or make them all the same. If you synchronize them so that you can remember them, you effectively make the most secure of your accounts equal to the least secure of your accounts.

But the auditors are happy. That's what really matters, right?

From 206.168.172.26 at 2008-05-23 09:26:43:

Actually, you exaggerated more than a little. I think you miss a key part of the problem, and are partially into absolute security land.

Forcing password changes is an unnecessary burden when workstations and all intermediary systems are run securely enough to keep keyloggers off, the passwords aren't accidentally stored in the clear (crypt hashing is cleartext :-) on remote systems not under your control, and so forth. That's Gene Spafford's argument, and it applies in his world; he's a careful user. But that's not the real world when it comes to less knowledgeable users connecting from random and often unmaintained machines.

To get to your conclusions, I think you're making the fundamental mistakes of considering security measures that don't provide perfect protection as therefore worthless, and considering only highly knowledgeable adversaries as worthy of protecting against.

In my real world, my users do have their credentials stolen. The crucial point missed in the absolute protection stance, however, is that the adversaries aren't perfect either. They can't always then get root, and they can't always repeat the credentials theft. In fact, in most cases root is not compromised, and the capture is not repeated after the user's password is changed. This suggests there's a real world prophylactic benefit for regular password changes.

That leads to the question of the time constant; how rapidly should the change be done? For higher value systems (ones with highly sensitive data, ones we can't rebuild quickly if the adversary does get root, etc.), we actually change the password each time the user logs in. We give the user a hardware token to generate those one-time passwords. Of course, even such one-time passwords won't protect against a compromised workstation with a knowledgeable adversary who can take over existing sessions, or run a local man in the middle. But again, most adversaries don't do that. This suggests there's even a real world prophylactic benefit for one time passwords.

Finally, my experience doesn't bear out your sidebar opinion that passwords are used immediately upon compromise. Especially lately, adversaries often have too many accounts to use effectively, or they have so many they simply overlook a few, only rediscovering them later. Even when they have the time and attention, however, a sizeable minority use one account on a host while leaving the other handful for which they have the credentials fallow (sometimes for years) for later harvest. Better still, they'll often remember previous passwords used, and retry them years later in the hopes that the user has switched back to them.

In conclusion, security doesn't have to be perfect to be useful, and not all adversaries are perfect either. In my real world of random users on random machines, credentials theft happens frequently, typically isn't repeated, and isn't always detected due to immediate misuse by an adversary. Requiring password changes, even given the hassle to the users of that practice, thus does have real world security benefit.

From 208.44.121.252 at 2008-05-23 09:27:49:

You are correct, although another purpose of rotating passwords is to change them before the theoretical time it would take to break the password through brute force or to crack the encrypted hash or whatever.

What do you suggest as a proper password change policy?

By rdump at 2008-05-26 23:47:10:

A proper password change policy is entirely organization- and user- dependent.

For one research organization, it's the following: real passwords need to be changed at least every 3 months, can't be reused, must meet minimal complexity requirements, must not be used at other sites (especially not on blogs/web forums and the like), and must not be in typical adversary brute force dictionaries.

This is appropriate for the organization because some password use is allowed from the general Internet (for email, typically), users are allowed to connect via VPN from machines not maintained by professional sysadmins, and we don't want users employing the same password they use for their slashdot account as they use for their time card submissions.

Given the legacy software support required, however, implementing that policy is not necessarily easy.

Written on 23 May 2008.
« Combining dual identity routing and isolated interfaces
Dear applications: WEP keys are not passwords »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri May 23 00:03:39 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.