Password Angst

I’ve written here before about the problems with using passwords as an authentication mechanism, especially when they are used in isolation.  Users, left to their own devices, tend to choose easily-guessed passwords; and, as with other security measures, they will work around restrictions that make it hard to get their work done.    As Prof. Ed Felten at Princeton has suggested, using passwords as a login authentication persists as a “worst practice“, because it is easy, the path of least resistance for the developers; besides, “everybody does it”.

Many organizations have detailed (and in some cases baroque) rules about the form of passwords (e.g., must contain a number and punctuation), password re-use, and required frequency of changes.   As is pointed out once again in an article at Ars Technica, in many cases these policies not only do not solve the problem, but actually make things worse.

Few common IT policies drive users to distraction as regularly and reliably as the aggressiveness of enterprise password policies.

But with more potential threats to enterprise security coming from external sources that take advantage of the users’ accounts once they’re already logged in, do byzantine password policies really do anything to protect corporate data? In some cases, the password policy may create a bigger security threat than the risk of a password being guessed.

In the first place, there are some attacks whose success has nothing to do with how “good” the password itself is.  If the users machine has been compromised and a keystroke logger installed, you lose, just as you do if the user discloses his or her password to a phishing or social engineering attack.  (And social engineering attacks are very common, often the first choice of serious hackers like Kevin Mitnick.)  Passwords that the user cannot remember tend to appear on PostIt notes or taped to the bottom of the keyboard.

Some organizations attempt to deal with guessing attacks by disabling a user’s login after a small number (<10) of failed login attempts.  This tactic, which dates back to the mainframe days, is reasonably effective; of course, if the user is legitimate, and has just forgotten the password, no work is getting done.  This means that the Help Desk has to get involved to re-enable the user’s account.  That takes time and costs money, so some sites use software systems that enable users to reset their own passwords.  Needless to say, these systems, like the “secret questions” used by Web sites, introduce their own security problems.

Even when we focus on preventing straightforward password guessing, the picture is not as clear as one might at first think.  There are at least two different guessing attacks to consider:

• A “dictionary” attack: that is, a system that tries to do an (approximate) exhaustive search of the space of possible passwords.
• An “educated guess”: someone who knows the user, or at least something about him or her, tries to develop a list of likely passwords.

The defense against the first attack mostly involves making the set of possible passwords large enough to make the search infeasible.  This generally means longer passwords are better.  A sixty-character passphrase will be pretty secure against this type of attack, even if we know that it is made up of concatenated English words.    On the other hand, length is not necessarily a defense against the second type of attack, if the phrase is sufficiently obvious for a particular user.

Probably the best security approach is still to use a multiple factor authentication model, based on the security trinity of “something you know, something you have, or something you are” (e.g., a password, a physical key, your thumbprint).   Magical solutions are, alas, still in short supply.

The article also references a good cartoon summary of some password ills, from the Web comic xkcd.