Password Expiration Policies
Directly after my Shmoocon talk on Rainbow Tables someone asked me how often should they force users to select new passwords. I was trying to get off the stage and make way for the next speaker so my reply was a bit disjointed, but the core of it was, "Password expiration policies are worse than useless when it comes to stopping password cracking attacks. They can be useful to limit insider threats, but at that point it becomes a policy, not a technical issue." Since this is a blog, I'd like to spend a little more time explaining that position.
With any security procedure, policy, or technical solution, it is very important to identify the problems you are trying to solve with it. When it comes to password expiration policies, most people's views are as such:
Myth 1) If a hacker breaks into our system, by the time they crack our password it will have expired so it won't do them any good.
Reality: Thanks to pass-the-hash attacks, most hackers don't need to crack your passwords in the first place. Even if that didn't work, they already have admin access to the box and keystroke loggers are wonderful things. Basically, you're already hosed and the password change policy isn't going to help you. Even if they gained access via an online attack, (aka they didn't break into the box but simply guessed the correct password. Think the twitter attack), a password change policy won't help you that much because the vast majority of people choose similar passwords when their own ones expire. Finally, there's the fact that a vast majority of passwords, (due to weak password hashes), don't require that long to crack.
Even worse reality: A password change policy invites people to be lax and sloppy with their password selection since they will just have to change it in a couple of months. Also it increases the amount of forgotten passwords, and the number of passwords written down. Finally it dramatically increases user frustration with security. User patience and acceptance of security measures is a valuable resource more important than any firewall or IDS. You shouldn't squander it needlessly.
Myth 2) If an attacker gains access and the password, it will kick them out of the system once we update our passwords.
Reality) That's cute. See the above.
So now that is out of the way, why am I being wishy washy and not saying to never use password expiration policies? Well, because I think it does help with two different problems to various degrees.
Problem 1) Helping to prevent against "Privilege Escalation Creep." I can't name the number of places where I've gone back a year latter for some reason and all my old accounts are still valid. Let's be honest, proper authentication revocation almost never happens when people leave, move on, or are promoted. This goes double for anyone who is a system admin, network admin, or basically has access to the good candy.
Where it can help: What a password expiration policy does is to help automate authentication revocation. If someone hasn't logged in to the system in six months, then they are locked out regardless if someone remembered to delete their account or not. For this to work though you have to have true password expiration. You have to lock the account after a certain amount of time. If they log in two years later and all the system does is force them to choose a new password this doesn't help. This actually can cause a lot of problems. You know that firewall that's been up for the last eight months? When it goes down and nobody can log into, that's a problem.
Problem 2) "The gossipy insider threat." Let's be honest, people share their passwords ... a lot. If it's 3am in the morning and the firewall is down, I'm going to be fairly receptive to the idea of giving the NOC guy my password so we can troubleshoot it over the phone.
Where it can help: If I change my password later, that persons access to my account is cut. This assumes though that I truly change my password instead of just going from "password1" to "password2". Also though my research I've found that once you know one password someone uses, it becomes much easier to break other passwords of theirs. "Wow they like !!!exclamation marks!!!", or "hey, they put numbers in front of their password."
What this means: When selecting a password expiration setting, it really does become a policy issue. The main questions should be "What is our concern about insider threats?" "How good are we are removing old accounts?" "Can we make it infrequent enough that we can convince users to significantly change their password when it does expire."
Personally I generally support a six month to one year password expiration policy simply to get rid of old accounts. I can see three months, but with the amount of passwords people have to remember I think that's a little too aggressive of a timeline and inches more into the self-defeating category. Quite honestly I think it is better to instead focus on getting users to use different passwords for different jobs. You can make a deal. "We won't make you change your password every three months, but we want you to use a different password when logging into the webserver vs the firewall." I think that would be more productive.
With any security procedure, policy, or technical solution, it is very important to identify the problems you are trying to solve with it. When it comes to password expiration policies, most people's views are as such:
Myth 1) If a hacker breaks into our system, by the time they crack our password it will have expired so it won't do them any good.
Reality: Thanks to pass-the-hash attacks, most hackers don't need to crack your passwords in the first place. Even if that didn't work, they already have admin access to the box and keystroke loggers are wonderful things. Basically, you're already hosed and the password change policy isn't going to help you. Even if they gained access via an online attack, (aka they didn't break into the box but simply guessed the correct password. Think the twitter attack), a password change policy won't help you that much because the vast majority of people choose similar passwords when their own ones expire. Finally, there's the fact that a vast majority of passwords, (due to weak password hashes), don't require that long to crack.
Even worse reality: A password change policy invites people to be lax and sloppy with their password selection since they will just have to change it in a couple of months. Also it increases the amount of forgotten passwords, and the number of passwords written down. Finally it dramatically increases user frustration with security. User patience and acceptance of security measures is a valuable resource more important than any firewall or IDS. You shouldn't squander it needlessly.
Myth 2) If an attacker gains access and the password, it will kick them out of the system once we update our passwords.
Reality) That's cute. See the above.
So now that is out of the way, why am I being wishy washy and not saying to never use password expiration policies? Well, because I think it does help with two different problems to various degrees.
Problem 1) Helping to prevent against "Privilege Escalation Creep." I can't name the number of places where I've gone back a year latter for some reason and all my old accounts are still valid. Let's be honest, proper authentication revocation almost never happens when people leave, move on, or are promoted. This goes double for anyone who is a system admin, network admin, or basically has access to the good candy.
Where it can help: What a password expiration policy does is to help automate authentication revocation. If someone hasn't logged in to the system in six months, then they are locked out regardless if someone remembered to delete their account or not. For this to work though you have to have true password expiration. You have to lock the account after a certain amount of time. If they log in two years later and all the system does is force them to choose a new password this doesn't help. This actually can cause a lot of problems. You know that firewall that's been up for the last eight months? When it goes down and nobody can log into, that's a problem.
Problem 2) "The gossipy insider threat." Let's be honest, people share their passwords ... a lot. If it's 3am in the morning and the firewall is down, I'm going to be fairly receptive to the idea of giving the NOC guy my password so we can troubleshoot it over the phone.
Where it can help: If I change my password later, that persons access to my account is cut. This assumes though that I truly change my password instead of just going from "password1" to "password2". Also though my research I've found that once you know one password someone uses, it becomes much easier to break other passwords of theirs. "Wow they like !!!exclamation marks!!!", or "hey, they put numbers in front of their password."
What this means: When selecting a password expiration setting, it really does become a policy issue. The main questions should be "What is our concern about insider threats?" "How good are we are removing old accounts?" "Can we make it infrequent enough that we can convince users to significantly change their password when it does expire."
Personally I generally support a six month to one year password expiration policy simply to get rid of old accounts. I can see three months, but with the amount of passwords people have to remember I think that's a little too aggressive of a timeline and inches more into the self-defeating category. Quite honestly I think it is better to instead focus on getting users to use different passwords for different jobs. You can make a deal. "We won't make you change your password every three months, but we want you to use a different password when logging into the webserver vs the firewall." I think that would be more productive.
Comments