“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
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.
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