Impossible Dream

It’s that audit time of year again, and password ageing comes up again. Across the sector there’s a wide variety of policies ranging from never expire to every 90 days and can’t reuse the last 20+.

So, is there any evidence for doing this?

If Mathematics is only concerned with three numbers (0, 1 and infinity) and computing with two (0 and 1) then maybe the place to start is with the difference between some ageing and none.

Before we can do that however, we need some threat models. What are we trying to protect against by forcing users to change their passwords? Here’s the six threats I came up with:

1. Password stealing malware
2. Passwords shared unofficially
3. Un-authorised use of shared accounts
4. Passwords that no longer meet the complexity standard enforced for new/changed passwords
5. Password guessing
6. Password cracking (e.g. with Crack or John the Ripper)

So lets test our long term change policy against this. Let’s say we age passwords once a year.

1. No gain. Any malware will have stolen the password within a day of being installed at most, and this policy allows plenty of time for the password to be used
2. Small gain. The users can just share the changed password again, and the effort required to do so once a year isn’t going to deter anyone from sharing their password, but we do mop up some cases where someone no longer wants to share their password (e.g. change of secretary). Of course, this shouldn’t be happening at all, but we all know it goes on to some degree
3. Win. When a member of staff leaves, they’ll retain access the shared account for at most one year, and, on average, for six months or so only. That’s not great, but it’s a lot better than the case with no ageing.
4. Big win. We know that within a fixed period, all passwords will meet our minimum complexity requirements
5. No gain. Password complexity rules help here (so there’s a knock on gain from 4) but no direct improvement.
6. No gain. Pretty much any password could be cracked in under six months anyway. We don’t even really limit the window of exposure much since the changed password will be just as vulnerable. Again, password complexity rules are what helps here (worth reading here: The Economics of password cracking in the cloud) since a good hash and strong password should resist cracking for a decent length of time.
   
   On a technical aside, if you are running md5 on the Unix side and NTLMv2 on the Windows side, cracking your passwords will be compute intensive given a decent complexity policy. Question for the audience - are you still running NTLM? I suspect you are :)

Given that analysis, I’d say it’s worth ageing passwords. Not everyone agrees: Fred Cohen still argues for no ageing at all (the link is from ‘97 but he repeated that view on a mailing list in 2009), but I’ve convinced myself :)

Now comes the really hard part. Anton Chuvakin posed this question recently:

What is the risk-driven, correct frequency of changing my email password?

and answered his own question thus:

<crickets…. silence… more silence>

Yes, we all can quote that “PCI DSS says 90 days” or “whatever regulation says 30 days”, but what does risk say? What actuarial information we need - if we are to define risk through probability of loss? What info about my email usage? Value of information stored there? Frequency of attacks on other similar email accounts? Chances of attack success? My approach to protecting the password? My personal password reuse “policy?” Anything else? On a related note, maybe this is simpler: what is my risk [of having the account compromised] if I change the password every 30 days, 90 days, 300 days?

So, any idea how to go about it?

This little experiment might well show us that “risk-based security” is an awesome thing – but not one achievable in this world today…

And he’s right. The question was discussed extensively on SecurityMetrics and the only conclusion is that there is no one magic number.

There’s a good discussion on possible attacks and numbers for password againg at Securosis.com (read the comments). Also NewSchoolSecurity asks Can Risk Management guide policy regarding password change frequency, which is a good starting point for how one might work out a number.

Here’s an exercise for the reader: given a 30 day aging policy, look at those 6 threats again and see if 30 days is better than 90 days, 120 days or a year, and if that gain is worth the pain. Consider the ease of password cracking in your environment, use of shared accounts etc.  It’s not easy.

So, there are we. I’d say that ageing passwords is a provable good, but that the time period is pretty much up for grabs.

Now let’s consider the external influences:

1. Users don’t want password ageing.
2. Auditors always want 90 days
3. Many research contracts now come with strong controls on how the datasets given are managed. Some recent contracts we’ve had specify password ageing every 30 days unless 2-factor auth is used, and every 90 days even then.

Point 3) is not one where arguing helps. If you want someone’s data to do your research, you’ll need to abide by their conditions. At least for now however, we’re finding that funders are happy that this condition only applies to users who have access to the data (this includes your sysadmins :) )

Points 1 and 2 are a dynamic tension. How much is your institution happy to push back against audit? Would it rather just enforce 90 days and be done? That’s a perfectly defensible decision, but when challenged with “where’s the evidence for 90 days”, you can now answer “there isn’t any”.

Edit: Chris comments “what about phishing, and is that broadly equivalent to threat (1) passwd stealing malware?”. Good point. I forgot phishing :) In terms of impact+mitigation though, yes, I think it’s the same as threat 1)