Wednesday, September 23, 2009

Does Size Matter? Picking a Sane Password Policy

If you choose a password made up of 60 random characters, it would take a hacker billions of years to crack it by brute-force. Pretty good security, all in all.

But since a password like that would be impossible to remember, it's not really practical for most end user applications. So how long should your corporate password policy specify that a password should be?

In the first piece in this series we looked at the desirability of choosing passwords made up of random characters chosen from as large a pool as possible--preferably including upper and lower case letters, numbers and special characters such as punctuation marks and symbols.

The SANS Institute recommends passwords should be at least 15 characters long, which effectively means that these password can't be carried around in end users' heads. Let's take a look at how secure a password this long would be.

If we take a scenario in which user passwords are made up of upper and lower case letters and numbers, each password character can be one of 62 possible characters. A fifteen character password thus has 62^15, or more than 750 million, million, million, million possibilities. That's a lot. If you got a pool of a million computers working on the problem, it would take about 2 million million years to check them all.

A healthy dose of realism is clearly in order. "A lot of guidance about password length and complexity is just a sticking plaster over an underlying problem with passwords," says Dr Ant Allan, a research vice president at Gartner.

"It's important to remember that if you increase length or complexity you are only defending against some kinds of attacks anyway," he says. "If the end user's machine is infected with spyware then the password will still be discovered, regardless. And a long password does nothing to prevent a hacker getting a password using social engineering. These types of policies are beloved of auditors, trotting out established ideas."

Fifteen is an arbitrary figure for password length, so what would happen if shorter ones were used? They would certainly be easier to remember, and since, as Dr Allan points out, security is only as good as the weakest point, the reduction in security would not be as great as it might at first appear.

The passwords might be a little more easy to crack, but since a ten character password would still take a great deal of time to crack, it's still far more likely that any security breach would come from an internal attacker, a social engineer, or through a malware attack than a successful brute-force attack.

Password Change Intervals

Password change intervals are usually also specified in corporate password policies, and the SANS Institute recommends that end user passwords are changed every four months. The rationale behind this is not clear: with this policy in force a hacker would still have an average of two months to exploit any password he acquired – more than enough time to do some harm.

Given that users forget passwords more often when they are changed regularly, and that there is a usually a significant cost involved in providing a help desk to reset large numbers of user passwords, you could argue that changing passwords is a fairly pointless but rather expensive exercise.

"There has certainly been an argument around for a few years now that changing passwords is more trouble than it is worth", says Dr Allan. "People argue that it prevents employees who leave an organization from exploiting their passwords after they have left, but this is just a cover for poor administration."

One possible solution to the problem of using passwords which are difficult to remember is to use a password manager.

These applications encrypt and store passwords securely for end users so they don't need to be written down, and ensure they can only be accessed by the user after entering a password.

The virtue of these systems is that users are only expected to remember a single password instead of numerous different ones. In the final piece in this series we'll be taking a closer look at this type of application.

No comments:

Post a Comment