On Security: Passwords and Identity

The question of identity on the Web is complex. Walk into a brick-and-mortar business, and the owner can recognize you as a regular customer. At minimum, he can check your driver's license or the signature on your credit card. Although it's certainly possible to fake physical tokens like these, it's not easy, and when a criminal has to be present to commit fraud, the risk and consequences of getting caught are high.

Transactions on the Web are altogether different. By its nature, Web traffic is somewhat anonymous. This presents a significant challenge for Web-based software that needs to know who is at the other end of a connection, and it presents an enticing target to criminals, who can perpetrate fraud from anywhere on the planet with little risk of being caught or punished.

The modern Web experience is not passive. We don't just go to the Web to sit back and read. At last count, half a billion people were using Facebook every month. Vast numbers of people are conducting business, managing projects, documents and financial transactions using Web-based tools on a daily basis. All of these interactive services need to reliably identify the person sitting at the keyboard.

As a set of technologies, though, the Web was not designed with identification in mind. Network traffic identifies the machines that are communicating, but not the people who are operating those machines. Various schemes have been created to meet this need and allow people to identify themselves to a Web application, but the traditional pattern, which most of us use every day, is the username/password system.

A username is analogous to a person's given name: it's an identifier, but it's generally not considered secret. The password, though, is what verifies that the person entering the username is indeed the correct individual. We're all familiar with the problems inherent to this system. Passwords have to be remembered, but they also have to be difficult to guess. These two properties are difficult to reconcile.

Identification systems generally look for one or more of the following factors to prove a person's identity:

1. Something you are, like when a shopkeeper recognizes your face or voice
2. Something you have, like a driver's license or credit card
3. Something you know, like a password

Each of these has strengths and weaknesses. Knowledge-based identification only works if the knowledge is secret. As soon as someone else knows or guesses a password, it no longer identifies an individual. But it's also the easiest to implement, since it doesn't require anything more than a brain. It's difficult for Web-based systems to make use of physical objects for authentication, although some software does use them. But until everyone agrees to use the same standardized system worldwide, broad adoption seems unlikely.

Password guessing is not just a theoretical problem. Servers across the globe are hammered all day long by automated software trying to guess common passwords and take over user accounts, which may then be used for any number of malicious purposes. In response, Web-based systems increasingly require a certain level of complexity in passwords, making them harder to guess. For example, if a password is required to contain at least one digit, it's unlikely to be found in an attacker's dictionary. Password reuse is also a concern. If I use the same password to access Facebook, Twitter, and my bank, anyone who obtains the password for one system can access the others.

In an ideal world, we would all use unique, completely random passwords for every application we access. But without using software or some other system to help manage all these passwords, the staggering number of systems that require login would make this an impossible task.

We don't live in an ideal world, and we can't let perfect security become the enemy of good security. In general, the following guidelines will protect the average user against most common attacks:

1. Use a different password for sensitive applications (banking and the like) versus those that are rarely used or untrusted
2. Even if an application doesn't have special requirements, don't use a password that could be found in a dictionary, or easily predictable sequences like "1234" and "qwerty"
3. Don't write passwords down, or if you must, make the written version different from the real password. For example, you might write all digits one less than the actual value, substituting "3" for "4" and simply remembering to add one when you use the password.