The Sin Explained

There are lots of things that can go wrong with password systems. First, we care about attackers being able to log into an account that isnt theirs and they have no right to use. This may not necessarily involve a password being compromised. For example, in a capture-replay attack, someone might be able to thwart the password protocol and log in without ever learning the password, just by sending a duplicate of some encrypted data.

Second, we care about attackers learning passwords they shouldnt have, not just because they can then log in to someones account, but also because that password is probably in use on other accounts. Or, at least, recovering one password might make finding the user s other passwords easier.

There tend to be plenty of easy ways to thwart password security. The easiest is often nontechnical: social engineering attacks are when attackers use their abilities to lie convincingly to meet nefarious goals. (This often involves having good social skills; otherwise , lies may not be as convincing.)

One common social engineering attack is to call up customer support, pretending to be user X and to have forgotten user Xs password. Particularly if you know enough personal information about your target, it can be easy to get the password reset.

People can often be tricked out of their passwords via a simple pretext, such as an attacker claiming to be a reporter doing an article on passwords. Phishing , where the attacker generally sends an e-mail convincing people to log into their accounts, and provides a link to a legitimate looking web site that is really just collecting usernames and passwords, is a less personal example of social engineering.

Another common problem that doesnt have much to do with the actual technical details of the password scheme is leaving around default accounts with default passwords. Often, people wont change them, even if the directions instruct them to do so.

One large problem can be that many passwords are going to be easily guessable if you let the user choose them. But if you dont let users choose them, or are too restrictive about what they can choose, then theyll be even more likely to leave their passwords written down in or around their workspaces.

There are other physical risks to passwords, too. Attackers can install key logging software, key logging hardware, or otherwise eavesdrop on password entry; for example, they can use cameras . This becomes even easier when a password dialog shows the password as the user types it.

There are other places to capture the password. Depending on the protocol, an attacker might be able to capture it on the wire. Or, an attacker might be able to capture it on the server end, either once it comes off the wire and is memory, or when its stored on the server. Sometimes passwords will get logged to log files, particularly when users mistype their usernames.

To avoid a server-side capture of a password, it is good practice not to store passwords directly, either on a server or in a database. It makes sense because the average user doesnt have much reason to trust people with physical access to servers, such as the sysadmins . Unfortunately, you have to store something related to the password, such as a one-way hash of the password, which is used to validate that the user knows the password. Any data stored server-side that is used to help determine whether a user knows a password well refer to generically as a validator . An attacker who can get such a validator can use a computer to guess passwords, and see if they produce the correct validator (often called an offline brute-force guessing attack , or a crack attack , due to the name of a popular guessing tool). Sometimes the task is easier than other times, particularly if the same password always gives the same validator. Theres a general technique well discuss called salting that helps make sure that the same password stored twice will produce two different validators.

Theres also the risk of client-side capture, particularly if its possible to store the password in a web browser or other local data store. This kind of single sign-on technology improves usability, but it can definitely create additional risk. Most people seem to find it an acceptable trade-off, though.

Offline guessing attacks can even happen on the network. Most authentication protocols will use cryptography to protect data, but attackers can usually get some cryptographic representation of the password that is subject to a brute force attack. Sometimes they can get it simply through eavesdropping, but they may have to masquerade as either the server or the client. If the password protocol is poor enough, an attacker can capture the clients data, replay it from another computer, and log in as the user, without even having to recover the password.

Of course, attackers can try an online brute-force attack, where they simply try to log in as the user numerous times, each time with a different guess. If users are allowed to have weak passwords, then this could eventually become a winning strategy. You can try to throttle login attempts or perform other intrusion detection measures, but if the consequences are an account lockout, it increases the denial of service (DoS) risk. For example, lets say that an attacker wants an item on an average online auction site, and the auction ends first thing in the morning on the East Coast. If attackers were watching to see who else was making high bids for the item, they can, in the middle of the night, try logging in as each of them, until they get locked out. Then, attackers have fewer competitors to worry about in the morning, as the bidders they locked out will probably spend their morning trying to get back into their accounts, instead of bidding, particularly since many such sites require you to fax personal identification.

There is also a class of problems called side channel problems , where bad guys can learn information about usernames or passwords by observing system behavior when trying out guesses. For example, if attackers want to target a system but dont know any usernames, they might try some candidates. If the system says invalid username, and has a different message for typing in a bad password, then attackers can easily determine when their trial and error has turned up a good username (one that they might target with a guessing attack). Look at Sin 13 for a real example of this bug in IBMs AS/400 e-mail server. Even if the system gives the same message in both cases, the answer might come back more quickly when the username is invalid, which would gives attackers another way to determine valid usernames.