Strike the Right Balance with Your Password Policy
Formulating password policy is a balancing act - a trade-off between usability and security
"The best password policy is not to use passwords at all." It's an old joke in security circles, but one that does highlight a very real problem: passwords are expected to play a key role in securing information and providing access to resources on many networks, even though striking the right balance between security and usability is a very difficult task indeed.
Here's the problem in a nutshell: passwords made up of long strings of random characters are hard to crack or guess, but they are also hard to remember. Simple passwords like "arsenal" or "labrador" are easy to remember, but also provide little security.
The role of a corporate password policy is to define rules for passwords to ensure that they are sufficiently secure. Perhaps the most important rules govern their make-up, length, and how often they should be changed.
The problem for network administrators is that when it comes down to it, these rules are arbitrary, so what should you consider when formulating a password policy to ensure the right balance is struck between security and usability?
The first line of attack for a malicious hacker trying to guess a password or crack a password hash is to try a list of "obvious" words, such as "password", the company name, the user's name, or the name of a spouse, child or pet if known. If this fails, the hacker will probably then run a "dictionary attack," methodically trying every word in a long word list. These lists will likely include letter and number patterns like "abcde", "qwerty", "asdf" and "12345", and common substitutions, such as replacing "3" for "e" or "5" for "s", as well as adding one, two or three digits before or after each word, or spelling dictionary words backward.
If a dictionary attack fails the hacker will then likely resort to a brute-force attack, trying every combination of letters, or upper and lower case letters, or upper and lower case letters and digits, or upper and lower case letters, digits and other characters (like $,%,^, & and so on) for passwords of increasing lengths. The main protection against this sort of attack is to ensure that every password in use is drawn from such a vast pool of possible ones that the probability of successfully brute-forcing the password in a reasonably short amount of time is acceptably small. This probability is affected in a big way by the character set that a password is drawn from, and the randomness of each character in the password.
To understand this, let's do a little math. If a password is made up of six random lowercase letters, then how many possibilities are there? The answer is 26 x 26 x 26 x 26 x 26 x 26, or 26^6, or 308,915,776, or about 300 million. If we assume a computer can check 10 million password guesses per second, it would take 30 seconds to check all 300 million of these six character passwords.
What happens if the password can be made up of upper and lower case letters (52 in all), plus the ten digits 0-9? Now there are 62^6 six character passwords (about fifty seven thousand million.) It would take about an hour and a half to check all these six character passwords.
What we can see from this is that increasing the pool of characters from which each character of a password is randomly drawn - by including upper and lower case letters and digits (and special characters if possible) - makes a huge difference to the amount of time required to brute-force it, and therefore increases the security of the password considerably.
What does this tell us about how password policy should be formulated? Ideally, that passwords should be made up of random upper and lower case characters, digits and special characters. But that assumes that the applications which require these passwords will accept all these types of characters. It also assumes that users can remember these random strings.
In the real world users can't easily remember long random strings - anything longer than seven characters appears particularly hard - so forcing them to use passwords made up in this way effectively forces them to write them down somewhere. This poses an internal security risk: that someone with physical access to the office - such as a co-worker or maintenance staff - will see the password written on a Post-It note and use it to access restricted resources or pass it in to someone outside the organization. What it doesn't do is make it easier for a hacker who breaks in to the network from outside to crack the password.