 |
| (Picture of Cliff Stoll, linked from Berkeley website) |
Note: I started writing this blog post in May 2011. Dropped some of my ideas, and have spent another 8 months to think, read and discuss the issues of password change frequencies. Now, at the time of publishing, I still haven't made up my mind. The "simple" question of How often should I change my passwords? isn't all that easy to answer.
First of all, I have the utmost respect for Professor Patrick Bours and Professor Christoph Busch, so no hard feelings in this blog post guys. I'll take this as a challenge, without doubt. ;-)
Here's what happened:
During my lecture, I said that in general I would recommend a password policy to require a minimum password length of 10 characters, and give users a 13 month change frequency as a reasonable tradeoff. I forgot to say that I've asked a lot of people if they would accept that, and almost everyone has considered that to be reasonable.
Somewhere else during my lecture, I showed password statistics based on data from a Windows domain, where LM as well as NTLM hashes were available. Naturally, LM hashes made things easy, so my statistics were based on having cracked 100% of the passwords.
I also said that I had successfully cracked a password of length 32 (or somewhere in that area), based on the NTLM hash and a user who had chosen a passphrase found on wikipedia with 2 digits applied to the end. A simple dictionary-hybrid attack using Cain overnight, using the popular wiki-wordlist by Sébastien Raveau recovered the password.
This is where Professor Christoph Busch raised his hand for some questions:
First question was how long time it took me to crack that length 32 password. I said "I was sleeping at the time, but maybe 8 hours?". His response got stuck in my brain:
"If your window of opportunity to crack a users password like this is - say 4 hours - why do you suggest a change frequency of 13 months, when it probably should be <4 hours?".... Being a password geek, waking up in the middle of the night with that question hammering your head is NOT pleasant at all. Damn you Christoph! ;-)
Now lets move to another part of the world, a long time ago during a penetration test, another guy came with some arguments regarding password change frequencies. Lets just call him "anonymous" for now, but he's yet another one of those guys that I really respect in terms of security knowledge. He simply said:
"If my password sufficiently strong in regard of length & complexity and stored with a reasonable hash algorithm, why would I ever need to change my password?"Oh; and at his organisation at the time, they didn't do mandatory password change for anyone. EVER. In fact, he said that starting mandatory frequent password changes would be over his dead body. He's still alive (...), and now they do frequent password changes. :-) Partially based - I guess - on the fact his Windows password got cracked in minutes.
Now if you spend a couple of minutes thinking about reasons for why you should change one or more of your passwords on something that even resembles some short of frequency (days, months, years) or other reasons, you'll probably come up with quite a few:
- (Corporate) policy enforces it - can't convince them into anything else
- Some external experts told me/us to do so (insert name/organization/url here....:-))
- I don't believe in research.
- I haven't opened my eyes.
- Oops. Sorry. Got a little carried away there. :-)
No, I'm not going to reveal my stance on this topic quite yet. I need to read that last paper there thoroughly. Twice.
However I would really like to hear your opinion:
How often, if ever, should we change our passwords?
I would be really happy if you reply with references to research, blog posts, articles, papers or anything else that can shed some more light on this subject. Yes, you can link to your own blogs and opinions. :-)
I asked almost the same question on Stack Overflow almost three years ago and got some interesting replies: http://stackoverflow.com/questions/767310/are-there-any-studies-for-or-against-frequent-password-changes
ReplyDeleteThat's a very good question Per. I've struggled with the same problem myself and don't have any good answers so I'm interested in what you and others have to say.
ReplyDeleteAs for my current opinion, I think that basing password change policies on most "time-to-crack" metrics is the wrong way to go. Let's look at the two main cracking scenarios:
Offline Attacks where the attacker stole the hash: If you don't know you were hacked, you're pretty much hosed regardless of how often you change your password. The attacker is going to keep stealing the hashes or just install a keystroke logger. There's a few edge cases where password changes can help but I don't think they occur often enough to justify a password change policy. Even then if an attacker has cracked one of your users' passwords, chances are cracking the next password is going to be pretty easy. Hey I even can reference the same academic study you did to back that assertion up ;) http://cs.unc.edu/~fabian/papers/PasswordExpire.pdf
Online Attacks where the attacker is blindly guessing passwords to gain access to the system: Your biggest threats here are "common/default" passwords and password reuse. Forcing people to change their password doesn't help if they pick 'password1' 'password2' 'password3'. As far as password re-use goes, that's a mixed bag. Some people say password change policies cause more password reuse, but at the same time it might force users to *slightly* modify their password so it isn't the same as the ones they have used everywhere else. The important thing though is that password change policies don't make the password a user chooses magically stronger.
That isn't to say password change policies are worthless. There are pluses. They can be used for account expiration, and as I mentioned earlier they might help with password reuse. Furthermore I know of at least one case where an insider threat was caught because one of his co-workers had shared their password with him, and he locked out their account when they changed their password.
None of this gets into the answer to your question though of how often should people change their passwords ;) Really my only point is that I don't think resistance to cracking attacks is a good metric to base password change policies on.
In my experience, the first battle to fight is getting your average end user to create and use password even getting close to any sensible level of password quality. Forcing frequent password changes is in that regard deeply counterproductive in all sorts of ways. And if your company's password hashes have leaked, reducing the window of exploitation of those passwords is quite often a moot point. -You're already as compromised as you can be.
ReplyDeleteI'm not sure why a 60-90 day change frequency window is so bad. In places I've worked, collectively over a thousand people have lived happily with such a policy.
ReplyDeleteI can completely understand when someone from the academic world (no offense, just generalizing) points out a problem like time-to-crack vs change frequency. There are other realistic value points to change policy than just time-to-crack. One assumption I often go by (not strongly, but it's a realistic assumption) is attackers aren't constantly cracking your passwords and aren't constantly grabbing them off the wire quite as often as us paranoid secgeeks think they are. Yes, it happens, but I would say more orgs realistically have a longer time-to-hack-and-crack time period. Sadly, we're not ever going to measure that. :) And I agree with anyone that still wants to assume it happens immediately. Yup, that's playing safe.
a- Changing your password helps mitigate incidents you don't know about. Granted, if an attacker secretly got a password, he can likely get it again. But why keep life easy? You might flush out some failed login attempts if you're diligently watching logs.
b- Changing your password helps assure that no one else knows it. As part of an IT department, user passwords simply get shared over time, whether someone's out of the office, a manager needs access, or the dekstop team is working on a system over a lunch break. Hard changes help assure that Joe down in IT doesn't still remember your easily memorable password when you shared it with him month to save a client. Yes, there are ways to work around these things, but business tends to go from point A to point B in the shortest path... Notice how this point stands up even with perfect encryption. Additionally, I'd personally, as part of the sec/systems team, be able to say I don't know Joe's password when someone uses that account to steal something.
c- Shared passwords on systems that aren't so stringent with their security. Out in the web world, this is a rampant problem where people use a banking password on a dumpy forum. The forum gets popped, passwd combo is exposed, and user may not even know it. Granted, this is a user problem, but an important system should take measures to reduce this problem if it can. (I'd say some of wouldn't even know a site we frequent has been broken into without the forced passwd resets. If crypt is perfect, why ever bother with that notice?)
I like 60-90 days, but not because of some empirical evidence or supporting measures. It really feels acceptable for most people, still allows for change, and is pretty easy, all told. There are so many other things in security that are problem points, many of which have no solutions and are just time vampires, that I'd hate to dwell on passwords too much in my role.
-LonerVamp
I tend to agree what that person you called "anonymous" said.
ReplyDeleteBetter create a single but strong policy which forces the user to use at least 16 chars. It must contain lower, upper, digits and symbols and no substring of the password is allowed to be found in a dictionary. Of course, such a password is hard to remember. But thats why you should not force the user to change the password each X days.
Password policies that force the user to change the password will start to annoy the user very soon and all you get is the users hate. They will search a way to exploit your policy. Maybe its enough to just append another "1" or something similar to their (simple) base-password.
I'd like to add to Matt Weirs comments and remind people (such as the anonymous gentleman in you article) that a lot of network protocols today expose information that can be used in an offline guessing attack (e.g. Kerberos). Focusing on "strength" of hashed password storage is misleading as long as these leaks exist.
ReplyDeleteThere probably will never be a "one size fits all" password change policy. Different sites will have different requirements. That's why I think it's important to specify what attacks password change policies protect against. That way you can determine what policy is appropriate for a particular situation.
ReplyDeleteFor example, shared accounts might have a password change policy so employees no longer requiring access will eventually loose access. The length of time would be dependent on the sensitivity of the resources being protected and expected employee turnover rates.
I just think "time to crack" is a measurement that doesn't hold up in reality. That's important to determine though. If you're basing your password policy on the "time to crack" argument then you might be causing unnecessary pain to your users. I strongly believe the amount of pain users are willing to put up with is finite, and I'd rather spend the "pain capital" on an annoying security control that actually do provide the benefits that I need ;)