Strike the Right Balance with Your Password Policy - Page 2

Because they are difficult to remember, many organizations are reluctant to specify completely randomly generated passwords in their password policies. Instead they prefer to specify that passwords must not include dictionary words, and must include both upper and lower case letters and numbers, or upper and lower case letters, numbers and special characters. The problem with this approach is that many users choose to comply with this policy in the most simple way possible: by selecting a password made up of letters starting with an upper case one, and adding a token digit, or a token digit and special character, on the end. A seven character password which includes upper and lower case letters and numbers can often end up being a 6 letter string starting with an upper case letter, with a digit appended on the end to comply with policy. Something like Gtindy1.

But how secure is this? It turns out that a password constructed by a user like this, while complying with the policy, is significantly less secure against a brute-force attack than one which is made from seven characters randomly drawn from the pool of upper and lower case letters and numbers. Here's why:

If the first character is always upper case then there are 26 possibilities. The remaining five lower case letters have 26^5 possibilities. And the final digit can be one of ten possibilities. So a seven character password which complies with the password policy is one of 26^6 x 10 (about three thousand million.) That's about a thousand times less than a password made up of randomly drawn upper and lower case letters and digits (62^7 or three and a half million million.)

But, and here's the important bit, a "which includes" password is much more easy to remember and therefore less likely to be written down. So although it is a thousand times easier to brute force this type of password, the internal risk is reduced. The tricky question is whether it is worth making it easier for an external hacker to brute-force a password in exchange for reducing the internal risk of someone reading and abusing a password that has been written down.

What all this goes to show is that formulating password policy is a balancing act - a trade-off between usability and security. It's easy to specify that passwords should be at least 50 characters long and must not be written down, but don't expect users to comply with that unless they have exceptional memories. And don't forget that secure passwords only protect against certain types of threats - they do nothing to protect your resources if spyware of keyloggers make it onto end user machines and email your passwords to hackers in the China or Russia regardless of how complex they are.

In the next piece in this series we'll be looking at two other key areas that are usually dealt with in password policies: password length, and password change intervals