A Little Rant About Passwords

August 24, 2006

A Little Rant About Passwords
By: Gary Hammock

Passwords are one of the most basic forms of data security. They are the first option that comes to mind when attempting to secure a computer system, network, or even a file. But at what point do passwords become cumbersome for legitimate users, but secure enough to retain data security?

Let's face it. The most secure system is one that is un-networked, only has one legitimate user, is encrypted, is unpowered, or basically hidden in the bottom of a well—but this is impractical. In order to actually use the computer, you must make some compromises. You must give legitimate users access while maintaining the integrity of your systems. This can be done through passwords IF they are properly administered.

You always hear people recommending weird entirely random passwords such as "#G018nW@$b!". While this may be secure, you try remembering that along with the other eight passwords you use for the other systems (you do use different passwords for each system, right?) Add to that the fact that most companies, governments, organizations, etc. require password changes every 30/60/90 days, and you have a lot of frustrated legitimate users. At what point does adding more rules reach a point of diminishing returns in security? You don't want your users writing their passwords down and leaving them beneath their keyboards.

Password strength is more dependent on password length rather than range of characters (with caveats). Granted, more potential characters helps, but let's look at the mathematics.

The number of combinations of a password is given by Cn, where C is the set of characters in use and n is the length of the password. A 10 character length password using only the 26 lowercase letters has more combinations than a 9 character length password using a 32 character set. 2610 > 329. This is an order of magnitude larger! As long as the 10 character password wasn't in a dictionary file (and thus subject to dictionary attacks), this would be an easy to implement password. Thus the password "iamrunning" is more secure than "*a#v!@$nb" and much easier to remember.

Let's do another one, shall we? Using that same first password (lowercase only), let's suppose a second set to be lowercase letters and numbers 0-9 while still maintaining the 9 character length. This means the second password has 369 possible combinations, which is still less than 2610. Therefore that same password "iamrunning" is still more secure than "password7" by still having a higher number of potential combinations. Of course this is a simplified model and the password "iamrunning" (though complicated combinatorally) may still be susceptable to dictionary attacks.

Now we could build an uber-password that utilizes the full unicode set and really make something complicated—but let's think on this. While you can (on Windows systems I know) enter unicode characters into the password prompt, it really seems to be counterproductive. In order to input a unicode character in Windows, you hold down the "Alt" key while pressing a four digit value on the number pad, such as alt+0192. While this may extend the character set, you still have to press five additional keys. If you had instead, used an additional five alphanumeric characters from the standard set, your password would be orders of magnitude stronger than a password with an obscure character set (pending a dictionary check, password length means nothing to a dictionary attack).

Now for something scary. An ATM has a character set of 10 digits, 0-9. For a pin number of four digits, this means a possible 10,000 combinations. Suppose a laptop can try a million combinations per second. This means a laptop would be able to crack an ATM pin in 0.01 seconds. DO NOT TRY THIS. THIS IS ONLY NOTIONAL AND HYPOTHETICAL IN NATURE. What do you think could help the most, a larger character set that must constantly be changed, or a few extra digits?