– Dr. John Linwood Griffin, Research Fellow at TeleCommunication Systems, says:
Why require your users’ passwords to look as though somebody sneezed on their keyboard?
To many users, password policies are as daunting and ridiculous as the tax code. Nobody enjoys having to remember or type complex and difficult passwords day after day. Even worse is having to change those passwords month after month for no reason.
Is your organization really better protected if your users are required to memorize a new 14-character password every two months? No! The new conventional wisdom on passwords involves three shifts in organizational thinking:
- Password policies should serve your users’ needs, not vice versa.
- Passwords shouldn’t be your sole means of protection.
- Simpler passwords can be better than complex ones.
The Purpose of Passwords
Passwords are designed to be positive, allowing your users to use your systems. A password check is a simple, intuitive and straightforward mechanism for enabling users to gain access to the network resources they need to do their job or to accomplish a task.
Your password policy and authentication system should be designed to be convenient for your users. When users find your password policy frustrating, difficult or annoying, nobody wins. In one notable example[1], a major e-commerce site required its users to click either a Login or Register button during the checkout process. The required login credentials were email address and password. This mandatory authentication step took place after the user clicked Checkout, but before the user was asked to enter payment information:
“The team saw the [login or register] form as enabling repeat customers to complete their purchase more quickly. First-time purchasers wouldn’t mind the extra effort of registering because, after all, they will come back for more and will appreciate the expediency in subsequent purchases. Everybody wins, right?”
Wrong. A formal user study revealed that the form primarily drove customers away. When the site replaced the Register button with a Continue [without registration] button, the number of completed customer transactions increased by 45 percent. In the first year after removing the password requirement, the site’s revenue increased by $300 million!
Keeping Bad People Out
Certainly, a secondary purpose of a password is negative—passwords can be a mechanism for preventing unauthorized users from gaining access to network resources. However, this preventive aspect of passwords is a far less important consideration than the overall usability of your authentication system.
That concept may seem strange at first. Why is keeping people out less important than letting people in? The answer is that just because a password is strong does not mean an attacker can’t obtain and use the password against you. It is a fallacy that stronger passwords always “raise the bar” against an attacker.
Strong or complex passwords, such as those requiring mixed cases with numbers or symbols, help protect against password guessing and cracking attacks. But guessing is only one mechanism used by attackers to obtain passwords. Other mechanisms include:
- Password reuse by users on other sites, or vice versa.
- Social engineering activities against users, such as phishing.
- Malicious software on users’ computers, such as keyloggers.
- A physical intruder checking under employees’ keyboards.
Complex and arduous passwords do not protect against any of these risks. On the contrary, requiring strong passwords increases the likelihood that users will reuse passwords or keep written copies at their desks. If your only defense against attackers is strong passwords, then you are not fully protected.
As discussed below there are supplemental ways, other than requiring strong passwords, to improve the security of an authentication system. However, there are few methods, other than user-friendly password policies, to improve the usability of a password-based authentication system.
Complex Passwords: A Best Practice?
Perhaps surprisingly, complex password requirements are not a best practice. Two scientists from Microsoft Research recently published a study[2]of password policies on 75 websites and found there to be “an enormous range of [password] strengths” with “little sign of an industry standard of preferred policy.” Instead, they observed little correlation between a site’s password requirements and its need for security:
“The size of the site, the number of user accounts, the value of the resources protected, and the frequency of non-strength related attacks all correlate very poorly with the strength required by the site. Some of the largest, highest value and most attacked sites on the Internet such as PayPal, Amazon and Fidelity Investments allow relatively weak passwords.”
The implication here is not that the security architects for these high-value sites are doing something wrong with their simpler password policies, but rather that they are doing something right that other companies and organizations are missing. In particular, these sites focus on authentication efficiency—they prioritize the common case of a valid user authenticating, and they add other security components designed to make that common case fast and easy for users.
The authors of the password policy study summarize their research as suggesting that:
“Much of the extra strength demanded by the more restrictive policies is superfluous: It causes considerable inconvenience for negligible security improvement.”
Supplementing Password-Based Authentication
One method for increasing the effectiveness of password-based authentication is to use information about the user’s computer system as part of your authentication decision. For example, make note of:
· The Internet Protocol (IP) address from which the user connects, or related information such as IP geolocation information or the user’s service provider.
· The browser information with which the user connects, such as the software, version number and operating system information.
· The existence of any browser cookies provided during a previous authenticated visit by the same user.
· The time of day and the day of week that the user connects to a service.
What is often important about these values is not the value itself but rather how they compare to the values from previous successful logins. If a user always logs into the email system from an office computer during working hours, then one day tries to log in with the correct password but at 1:17am from Kyrgyzstan, then it would be appropriate for the system to automatically take additional authentication steps before permitting access to network resources.
These additional authentication steps could be drawn from any of the well-known two-factor authentication schemes: something the user knows, or something the user has. The important usability consideration is to escalate the authentication to require a second factor only when it’s dictated by the circumstances—for example, when the user connects from an unknown location or when the user connects to a high-value network resource.
Four Random Common Words
A great example of a strong but usable password policy is a group of four unrelated random common words—e.g., ‘correct horse battery staple’. That passphrase is simple (it contains no number-for-letter substitutions), contains only lowercase letters, is easy to remember (see the graphic depiction by Randall Munroe at http://xkcd.com/936), yet is resistant to password-guessing attacks:
· A brute force attack against ‘correct horse battery staple’—a 28-character password with 27 possible symbols (the letters a through z plus the space symbol)—has a search space of 2728 or 11,972,515,182,562,019,788,602,740,026,717,047,105,681.
· A sophisticated attack against ‘correct horse battery staple’, where an attacker guesses four randomly selected words from a 2,048-word dictionary (say, the 2,048 most common words in the English language), inserting a space between each word, has a search space of 2,0484 or 17,592,186,044,416.
Seventeen trillion possible passphrases provide ample protection for an Internet-facing server that is configured only to accept incoming requests at a rate of 1,000 per second. It would take a sophisticated attacker more than 557 years to submit all the possible passphrases for just a single username.
Even stronger—but harder for users to remember—is a passphrase that consists of five common words. In fact, a sophisticated attack against a passphrase of five lowercase words separated by spaces (2,0485or 36,028,797,018,963,968) is a greater challenge for an attacker than a brute-force attack against an eight-character password selected from the full set of 95 printable ASCII characters (958 or 6,634,204,312,890,625).
Unfortunately, studies have shown that users do a poor job of choosing good random passwords. Passphrases based on common words are especially vulnerable to users choosing well-known phrases such as ‘bringing home the bacon’. If organizations implement a policy based on random common words, they must be aware of the need either to validate a user’s choice (rejecting common phrases) or to provide a random-passphrase generator from which the user selects a passphrase.
User-Friendly Password Policies
Policy decisions should be based on a sound technical and risk analysis of your authentication systems, plus a solid understanding of the needs and convenience of your users. In the example above, part of what protects against a password-guessing attack is the 1,000-requests-per-second limit of the single server. In an environment with more servers, no incoming request throttling, or no logging of failed authentication attempts, an attack against a four-word passphrase is more feasible.
Another aspect of user-friendly password policies is the frequency of required changes. Once you’ve helped your user memorize a strong enough password to protect against guessing attacks, consider letting the user keep that same password for at least a year. You can instead use supplemental security mechanisms—those described above, plus auditing, profiling and log analysis tools—to detect when a password has been compromised.
A related option is to provide a user with a list of one-time passwords for use in high-risk situations, such as during foreign travel. A professor from Purdue University notes[3]:
“Forcing periodic password changes given today’s resources is unlikely to significantly reduce the overall threat—unless the password is immediately changed after each use. This is precisely the nature of one-time passwords or tokens, and these are clearly the better method to use for authentication, although they do introduce additional cost and, in some cases, increase the chance of certain forms of lost password.”
It’s important to make a decision on password policies and systems protection that works for your environment instead of just guessing based on what other organizations have done.
Am I Secure Yet?
“Secure” is an ambiguous goal. An organization should be prepared for its security system to fail. It is certainly important to have reliable authentication policies and practices, and to consider deploying secondary authentication systems, and to monitor for unusual activities in log files or other network records. But it is equally important to be able to detect, analyze and recover from successful attacks—especially when you can only detect a successful attack after the fact.
Usable security policies, including user-friendly password policies that focus on the positive goal of allowing users access to the resources they need, will not reduce the security posture of your networks and systems. On the contrary, making it easier for your users to comply with your password policies will likely improve your security posture, as fewer people try to circumvent the measures you put in place.
About the Author:
Dr. John Linwood Griffin is a Research Fellow at TeleCommunication Systems (TCS), Inc., where he leads research and engineering programs on computer and communications security. He earned Doctor of Philosophy and Master of Science in Electrical and Computer Engineering degrees from Carnegie Mellon University. He earned a Bachelor of Science in Computer Engineering degree from Auburn University, where he graduated summa cum laude and as a University Honors Scholar. He has written and taught academic and industrial courses on computer storage, security, and networking and has co-authored refereed conference, journal, and workshop papers. Among the honors, grants, and awards he has received include an invitation to participate in the U.S./Japan Experts’ Workshop on Critical Information Infrastructure Protection, an Intel Foundation Ph.D. Fellowship, and a National Science Foundation Graduate Research Fellowship.
[1] Jared M. Spool. “The $300 Million Button.” Published January 14, 2009. Available at http://www.uie.com/articles/three_hund_million_button.
[2] Dinei Florêncio and Cormac Herley. “Where Do Security Policies Come From?” Published in the Symposium on Usable Privacy and Security (SOUPS) 2010, July 14-16, 2010. Available at http://research.microsoft.com/pubs/132623/wheredosecuritypoliciescomefrom.pdf.
[3] Gene Spafford. “Security Myths and Passwords.” Published April 19, 2006. Available at http://www.cerias.purdue.edu/site/blog/post/password-change-myths.
