Why Password Wisdom Is All Wrong

I don't like to keep people in suspense, so I'll start off with the surprise ending: Your password is not secure. Now that I've gotten your attention, we can talk about why that is (and what you can do to improve upon it).

Let's start with the basics: What makes a good password? You've probably heard variants on this from many different places over the years. "Your password should consist of numbers, letters, and punctuation. It should be at least eight characters long and not contain your name, birthday, pet's name, or Social Security number."

I'm sorry to tell you this, but you have been lied to.

The simple truth is that passwords of that level of complexity are of extremely poor value in the real world. Brute-force attempts to try every possible combination, while inefficient, could crack your password in a few days or weeks of dedicated work on modern computers. Beyond that, despite the recommendations above, people tend to use passwords that are easier for them to remember (such as a common word or name, followed by a few numbers). Passwords of this nature are even easier to figure out, because the base words from which they originate (as well as common manipulations, like substituting a zero for an "o") are often gathered into "dictionaries" of routines for attackers to try.

There are other problems inherent in these password requirements, beyond the basic mathematical limitations. The degree of complexity is easy to measure with arithmetic, but it's very hard to put a number to "How hard is it to remember?" The more complex the password requirements get, the harder it is to remember that password. This is, of course, a qualitative judgment. Some people are perfectly capable of remembering 15-character jumbles of random letters and numbers. Those of us who are mere mortals tend to have difficulty with this.

As computers get faster, our only solution has been to increase the length of our password requirements in order to stave off the increase in computational speed necessary to break them. So eight characters may have been sufficient 10 years ago, but now passwords need to be a dozen or more in length before they are "unbreakable" -- until computers catch up. In the meantime, we've rendered passwords so completely impossible to remember that nearly everyone is forced to store them written down somewhere.

Any security professional will tell you that once a password has been written down, its effectiveness is reduced immensely. All it takes is for one person to get a quick snap of your Post-It note with a cellphone camera, and all of the company's carefully constructed security policy is worthless.

So what do we do? How do we manage to control access to our computers without either using insecure passwords or forcing our users to write them down to remember them? Well, there are several ways. The first would be to use a second form of authentication (such as a smartcard or time-based authentication token). This means that you can theoretically reduce the password-complexity requirements, because your access now relies on more than just having your password. You also need some physical device on your person. This makes an attack much less likely to succeed (since you'll notice that your authentication token is missing).

There is a second approach that more and more companies are starting to become aware of. As I mentioned in passing above, the biggest gain with passwords (mathematically) is with length, not character complexity. So a fair number of companies have started reducing the number of required characters and instead are simply relying on longer passwords. This can result in much easier-to-remember passwords. For example, instead of a random sequence of letters, numbers, and special characters, a company could require that your password only require letters and spaces, with no upper limit on length. Employees could be encouraged then to just pick several English words and remember the order, such as "vagrant pizza mouse garden pick." This is a much simpler phrase to remember than "p1ZZapi3" would have been, and at the same time, it is much more secure, because of its significant length. This second approach has effectively zero cost to a corporate environment while providing a significant gain in security.

— Stephen Gallagher is a Linux Software Engineer working at Red Hat, Inc.