Revised June 15, 2002
It's very common these days for computer users to be told to periodically change their passwords. Many systems go so far as to "expire" each user's password after an established period of weeks or months. Security experts have traditionally insisted on password expiration to foil an attacker who intercepts or guesses the older password. Once the user has switched to a new password, the attacker shouldn't be able to use the older password. In practice, however, password expiration doesn't achieve these goals. In some cases it may actually make matters worse.
Password expiration poses a real risk to today's computer users who rely heavily on their desktop computers -- when users lose or forget a password, they often face a serious interruption of their workday. The highest priority for most users is to ensure that they won't accidentally forget their password, and they run this risk every time their password expires. People use a variety of mechanisms to cope with this, like choosing passwords from a memorable sequence or by writing passwords down. These coping mechanisms often eliminate the benefits of password expiration and can even increase security risks.
The first issue to consider is the impact of password expiration on the site's productivity. Clearly, password handling is an unproductive, "overhead" activity whose impact should be minimized for practical reasons. Yet the traditional password changing process is one of the more challenging tasks a user must face.
Consider what a user named Cathy must do when her password expires. Traditionally, the system will simply demand a new password the moment the previous one expires, and Cathy must provide the new password in order to proceed. Fortunately, some systems make this slightly easier by issuing warnings a few days before the password actually expires.
If Cathy is like most people, she's unlikely to spend idle moments trying to think up a clever, memorable, but hard to guess password. When faced with the expired password, she must immediately think of one and accurately type it without seeing its text, since most systems don't like to display passwords. It is particularly difficult for people to memorize text without ever seeing it
As if this isn't enough of a mental challenge, consider that human short-term memory can, on average, remember between five and nine things of a particular kind: letters, digits, words, or other well-recognized categories. Many organizations require eight-character passwords, which lie on the optimistic end of peoples' ability to memorize. Moreover, Cathy's short-term memory may only retain this new password for a half minute, so she must immediately memorize it. Studies show that if Cathy is interrupted before she fully memorizes the password, then it will fall out of her working memory and be lost. If Cathy was preoccupied with a different task when the system demanded a new password, she must sacrifice either her concentration on the critical task or the recollection of her new password.
It's not unusual for memory to fail and the password to be lost. Then Cathy must contact the site's help desk and arrange to have her password reset. According to a study by Forrester Research, 20% to 50% of all help desk calls are password related, and these calls cost the site an average of $80 each (see "A digital certificate roadmap" by Forrester Research, 2000). Moreover, the help desk itself can open the site to attack, especially when handling "lost" passwords. In a typical attack, the help desk receives a call from a panic-stricken user whose password doesn't work. The help desk gets the user logged on, and it later turns out that the "user" is really an attacker.
Another common strategy is for users to choose passwords out of a series ("secret01" "secret02" "secret03" and so on). This easily and conveniently satisfies the system's demand for a new password whenever it might happen, and Cathy only has to remember the base word ("secret") and the number she's used most recently. If she forgets what number she's on, she can probably guess it while making only a couple of unsuccessful attempts. Unfortunately, the same is true for an attacker.
Remember the reason for password expiration: we want to prevent attackers from making use of an older password. But the attacker doesn't have to think very hard about what to do if a password like "secret02" doesn't work: no doubt the password "secret03" or "secret04" will work instead. A few systems try to prevent users from choosing such passwords by looking for such patterns, but people can always construct patterns that computers can't detect.
Another pattern that's slightly better (and almost impossible for a computer to detect and reject) is to choose pairs of words from a memorable song, poem, or prose quotation. For example, Cathy could start with the password "WayDown" and then use "UponThe" and then "SwaneeRiver". Attackers might have a little trouble guessing that sequence unless they've intercepted that third password.
There is an even more "secure" approach based on memorable text: instead of using whole words, you construct the password from the first letter (or last letter) of each word in the text. When it's time to choose another password, use the next section of the text. If we use the words to "Swanee River" as discussed above, the first two lines would yield "Wdutsrffa" as a password. One problem with such passwords is that people rarely memorize long sequences of text, except perhaps the words of songs. The words in a single song won't usually provide more than a handful of passwords in a sequence before the user has to start over with a different one.
The British military used this letter-based approach to construct the secret codes used by spies during World War II. They reasoned that they could construct relatively strong codes by taking advantage of texts that people had already memorized, like notable poems or famous prose. If the spy in question didn't know an appropriate text by heart, famous words were often practical to memorize. However, this approach yielded a serious problem: people didn't always remember the texts perfectly. The same problem can plague users who are trying to generate sequences of passwords. A user can lose the new password by remembering the text one way when creating the password, and then remembering it differently when trying to log on.
After facing troubles memorizing random passwords and constructing passwords from pieces of text, users often fall back on paper: they write the password down and keep it in a convenient place. This often happens even when local rules forbid it: surveys by the author have uncovered written passwords near workstations at least 4% of the time (coincidentally, about 4% of users choose a password that matches their user name). In sites that require periodic password changes, however, the rate has been as high as 39%.
Under the best circumstances, then, an attacker can uncover a password by searching 12 or 13 desktops in well-behaved sites, and as few as 2 or 3 desktops in some sites. This thoroughly undermines the security objectives sought by periodic password changes.
Written passwords aren't necessarily a security problem, but they can be. Written passwords obviously make it easy for an attacker when users simply leave them near workstations. Many site policies discourage written copies of passwords simply because it's difficult to educate people on how to protect the written copy. However, written passwords may be the only practical solution if the site really needs to use hard to memorize passwords. The site can minimize the risks of written passwords by instructing users on how and where to safely store written passwords.
Even though password expiration is a burden on the user community that often has either a negative effect, or no effect, on site security, it currently plays a prominent role in password management policies. The author recently reviewed the password policies of 40 different organizations and found that 60% of the policies either required or recommended periodic password changes. Forty two percent of the policies indicated that users' passwords would automatically expire every few weeks or months.
This is unfortunate, since site administrators are obligated to follow their site policy, even when its requirements don't yield the best results.
In 1985, the Department of Defense published a Password Management Guideline that described how to compute the "strength" of a password in terms of how hard it was to guess through trial and error. The implicit logic of the Guideline's approach is that you can always make a password stronger by making it longer and/or using a larger character set. By implication, you ensure the passwords are strong by requiring a mixture of upper- and lower-case letters, digits, and punctuation marks. The mixture suggests that the user hasn't simply picked a memorable word that might be in a dictionary, even though the user probably won't need to write the memorable word down.
In practice, people adapt to these complicated rules and restrictions. Some people come up with simple sequences of memorable passwords that look okay to the password management software. Other people make up arbitrary, hard to guess passwords and save them on Post-it notes. In either case, the passwords aren't as hard to guess or intercept as the security policies intend. Passwords are weak because there's a limit to how well people memorize random secrets. Since passwords are essential to make today's computers work, people will take whatever steps they find necessary to remember their latest passwords.
As a practical matter, most organizations don't spend money on security until after they've suffered a significant loss. For example, Citibank was using simple passwords to protect multi-million dollar cash management accounts until 1994, when an international ring of embezzlers used intercepted passwords to steal millions from those accounts. Now, Citibank uses authentication tokens to protect those accounts. If a site relies on computer-based authentication to protect valuable resources, then it really needs to use a stronger technology than passwords.
For further information on authentication systems and technologies, see the author's book Authentication: From Passwords to Public Keys.