Most Password Policies Are Bad

I want to preface this post with a couple of disclaimers.  When I talk about passwords in this post, I'm talking about the ones that matter.  I'm talking about your Windows Login password or your Internet Banking password, not the password you use for Facebook or Digg. Let's be honest, nobody really cares enough about those accounts enough to break into them.  Also, I'm not going to address how the password is stored or the physical security of the resources.  Ideally, there'd be more than just a password.  However, for the purposes of this post, I'm assuming that the password is the only way in.

Now to my blunt opinion.  Most password policies are bad.  They fail spectacularly to solve the problem they're meant to solve.

Usually, password policies (particularly in workplaces or universities) enforce a few rules.  Some of these rules are useful and some aren't.  So called "standards" or "industry norms" are followed, but there seems to be little thought put into the password policy.

A large number of password policies I've come across follow these two rules:

• The password must be technically complex, usually judged by a basic algorithm; and
• The password must be changed frequently.

First, let's look at the problem a password is meant to solve.  Obviously, a password is meant to prevent unauthorised access to a particular resource; usually a computer, a network, or some software.  The assumption is that unauthorised access is bad and must be prevented, and don't worry, I'm not going to argue with that.

So, looking at the first password policy rule listed above, does having a technically complex password solve the problem of unauthorised access?

The problem is that true complexity is very difficult to judge with software.  If a judgement is made on a character-by-character basis, it is essentially useless.  A password like MyPa$$w0rD for example, will almost always be judged as technically complex, but would be relatively easy for a sensible password cracking algorithm to break.  It's not enough to assume a password is good because it meets your easily-testable rules.  I submit that the only good way to test whether a password is secure is to try your hardest to break it.

Enforcing a rule that makes sure a person has a certain number of characters and that they belong to several different character groups (uppercase, lowercase, numbers, symbols) means that a brute-force attack would probably be infeasible.  But as a software developer, if I really wanted to find someone's password, there's no way I'd be doing a blind brute-force attack.  I'd start with a dictionary of common words and I'd add things like the person's date of birth, their partner's name, their children's names, their pets' names - essentially any personal information that I could find.  I'd write some code to try things in a sensible way using these words prefixed or suffixed with numbers or other characters.  I'd try changing the letter O to the digit 0, i to 1, a to @.  Of course in the end, I'd probably just find a tool that did all this for me, but I wouldn't just go trying random characters.

So does the first rule meet our goals?  Does enforcing 8 characters including three different groups guarantee a good password?  No it doesn't.  You can set a terrible password and still follow the rules.

Onto the second rule - regularly changing the password.  Let me first say that this is a rule I hate.  Not only does it not meet the goal of protecting an account, it actually makes things worse when combined with the first rule.  Let me explain.

The reaction most users have when you tell them their password has to be (for example) at least 8 characters long and contain uppercase, lowercase, and numbers is not entirely positive.  It's not always easy to think of a password that meets all of these requirements as well as the unspoken one; you have to remember it.  For obvious reasons, unless they're instructed otherwise most people will choose something easy to remember like their surname followed by their birthday.  It meets the requirements and they can remember it.  To combat this, sensible administrators will explain how important it is that the password can't be guessed and encourage another method of choosing a password.  They might suggest turning a sentence into a string of characters.  For example, the sentence "I'm going to try to remember this password" could become "ImG2t2RthP@ss".  That's a pretty good password - it meets all the rules, it looks very random, it will survive a dictionary attack, and most importantly it can be remembered.  Basically, it's going to take a very long brute-force attack to guess.

Now, what if they know they'll have to choose a new one to remember every month? Are they going to pick a hard password then?  I'd suggest that it's far less likely that they'll go through this process of turning a sentence into a password every month.  Even though it's easier to remember than a random string of characters, it's won't stick instantly.  It might take them a few days before they can type it without thinking.  And if they have to do this every 30 days, it becomes that much harder to properly cement it in.

The user is thinking, "why do I have to change it?  My last password was good enough!", and you know what?  They're right.

The common argument is that a password should be changed frequently in case it gets compromised.  If someone discovers the password, they'll only be able to access the system until it's changed.  While this may be technically true, what does this really accomplish? How long does it really take for someone to do whatever they wanted to do by gaining access to your computer?  The fact is, as soon as someone else is able to access something they shouldn't access using your password then that's it - mission failed.  Are you really going to hang the strength of your security on the hope that the attacker won't have enough time to do what they want to do before the password changes again?  It's made even worse by the fact that the password is less likely to be a good one.  If I discovered that your current password is "January101182" or "Smith111, it probably won't take me long to work out your next one.

To summarise, a password policy like the one in the bullets above that enforces some level of technical complexity and makes the user choose another one every month fails in a couple of ways.

Firstly, enforcing technical complexity is the ultimate false sense of security.  It doesn't force a user into choosing a good password.  In fact, combined with a rule enforcing frequent password changes, it encourages bad passwords.  Also, the warm fuzzy feeling the admin gets from knowing a password is at most 30 days old is fools gold.  The damage is done as soon as the password is discovered, and it's more likely to be discovered with a 30 day turnaround because the password will be worse.

I know this is an essay already, but it would be unfair of me to end after attacking common practice without offering an alternative.

So here's what I suggest:

• Passwords should be technically complex, but they must not be easy to guess; and
• Passwords should be changed at most once a year unless there's a suspicion they've been compromised.

Instruct each user to use a method like the the one suggested earlier; compressing a sentence to choose a password.  Make it hard - 10 or 12 characters in all four categories.  They won't have to change it regularly so who cares if they take a while to remember it.  If they absolutely need to, let them write it down and keep it in their wallet until they remember it.  If they lose their wallet, then change the password.

Of course as I mentioned earlier, the only real way to test the strength of a password is to try to crack it.  So do that.  Set up a simple system that stores a hash of the person's password, and try to break in using whatever means necessary.  In particular, look for personal information to work with.  If it's too easy, you should be able to break in quickly, and if you do, make them change the password to something harder.

So there you have it.  My opinion on why most password policies are bad.  Sometimes you actually have to revisit the problem you're trying to solve rather than just follow so called tried-and-true policies.

-Damo