by George Taniwaki
For the past several months, every time I log into my bank’s website, there is a reminder that I should change my username to something more secure and change my password since I haven’t changed it recently. I’ve been ignoring both messages and there don’t appear to be any adverse consequences to my inaction. But I’ve decided to do some investigation regarding username and password best practices so that I could decide if my sloth and laziness are justified. I summarize my finding in this blog post.
My bank’s reminder. Image from Charles Schwab
Creating secure usernames
I tend to use the same username on all websites. Should I actually be using a different one for every site? Roberta Bragg, a security consultant, posts a knowledgebase reply that says she knows of no research that shows this increases user safety. On the website administrator side, she says that allowing users to change their usernames after initial registration can be an administrative burden and can actually create a security hole. For an example of the havoc that changing a username can cause, check out Episode 4 at TheWebSiteIsDown (warning NSFW).
Nearly all websites require a username and password combination to access system resources. Websites that use this access protocol require that usernames be unique, but do not require that passwords be unique. Usernames are often made widely available, so that users can contact each other for instance. Thus, I feel safe not changing the username I use to log on to my bank’s website.
Since usernames are widely available, access security is maintained as long as a malicious user cannot easily guess or uncover the password associated with a specific username, or guess or uncover the username(s) associated with a specific password.
Creating secure passwords
Let us assume that a malicious user has obtained a list of all usernames to a system but does not have a list of the corresponding passwords for those users. What can the malicious user do to try to breach the system? What can the system administrator do to mitigate this threat? And what can users do the reduce the threat that they will be the victim of an access breach?
The first thing that a malicious user will do is try different passwords with each username. A brute-force attack would use every possible combination of characters up to the length limit allowed by the website administrator. This would be extremely inefficient.
An excellent best practices paper from Hitachi shows how increasing the size of the character set and length of the password increases the number of possible passwords, making a brute-force attack more difficult. Assuming that passwords are randomly selected (which is not true), this is also the size of the search space for a brute force attack.
|Character set (size)*||5||6||7||8||9||10|
|a-z, 0-9 (36)||6.05E+07||2.18E+09||7.84E+10||2.82E+12||1.02E+14||3.66E+15|
|a-z, A-Z (52)||3.80E+08||1.98E+10||1.03E+12||5.35E+13||2.78E+15||1.45E+17|
|a-z ,A-Z, 0-9 (62)||9.16E+08||5.68E+10||3.52E+12||2.18E+14||1.35E+16||8.39E+17|
|a-z, A-Z, 0-9, symbols (94)||7.34E+09||6.90E+11||6.48E+13||6.10E+15||5.73E+17||5.39E+19|
*Number of characters in the set
A much faster method of finding passwords is to obtain a list of common passwords and a rank order of their popularity. This will allow what is called a dictionary attack where each popular password is tried with each username until a correct guess is made.
So how efficient would a dictionary attack be? The data security firm Imperva has published a white paper that provides some statistics on popular passwords. The report is based on an analysis of 32 million passwords that were exposed by a breach of RockYou, a social media site. A dictionary attack using just the single most popular password among RockYou users (123456) would provide access to nearly 1% of accounts. The top 400 passwords would provide access to about 7% of all accounts, while the top 5,000 passwords would yield about 20% of all accounts. The top ten most popular passwords are shown in the table below. (For the moment, we will ignore the question of why RockYou was storing customer passwords in plaintext format.)
|Rank||Password||Number of users|
According to Imperva, almost all of the top 5,000 most popular passwords were “trivial”. That is, they were names, words, consecutive digits or letters, adjacent keyboard keys, or common phrases. Beyond a dictionary attack, a password guessing algorithm can be expanded by combining a root with a prefix or suffix, or creating a text corpus from the user’s hard drive. These techniques are described in The Guardian Nov 2008.
Notice in the table above that the password 123456 is about three times more popular than 12345. I’m guessing RockYou users know that 5 characters is the minimum length password and so just to be safe choose a 6 character password. Yeah, that will stop those malicious hackers.
So what is a strong password? Microsoft has a TechNet article that suggests a strong password has the following characteristics.
- Is at least seven characters long
- Does not contain trivial patterns (username, proper names, dictionary words, etc.)
- Contains characters from each of the following four groups: uppercase letters, lowercase letters, numerals, and symbols
Note that your responses to the secret question that resets a password should have the same characteristics as above. Your secret pet’s name should not be “fluffy”, your secret high school should not be “jefferson”, and your mother’s maiden name should not be “smith”.
Most people have seen or heard of these recommendation. But many don’t follow them. First some good news (of sorts). The Imperva study shows that among RockYou users, 70% used a password that was 7 characters or longer. Only 4% used a password 5 characters long (the minimum allowed) while 26% used a password 6 characters long. Now for the bad news. Nearly 60% of passwords contain only lower case letters, only upper case letters, or only numerals. Only 3.8% of passwords contain any symbol characters and only 0.2% of password met the requirement of being 8 characters or longer and contain a mix of all four character types.
Changing passwords periodically
A separate Microsoft TechNet article provides the following best practices recommendations:
- Always use strong passwords (see above)
- Passwords may be written down on a piece of paper, but store the paper in a secure place and destroy it when it is no longer needed
- Never share passwords with anyone
- Use a different password for each user account (and make each significantly different). Passwords that increment (Password1, Password2, Password3 …) are not strong
- Change passwords immediately if they may have been compromised
Note that there is no suggestion to change a password on a regular basis. And yet that is a common requirement for many websites and to log into a computer. The Hitachi best practices paper recommends setting a password expiration policy such that it is shorter than the amount of time for a brute force attack to succeed. This means as computers get faster, we will need to change passwords more frequently. An entry in DailyBlogTips also recommends regularly changing passwords.
However, others disagree. At the end of an entry in Eric Wolfram’s blog, there is a comment from Tim McNerney that argues that users should never be required to change passwords. His logic is that users forced to regularly change their password will pick passwords that of lower quality than if they were only required to create it once. He also says that assuming the malicious hacker is not using the brute force method to break the password, it will take much less time than a reasonable expiration policy period to compromise the system. This same logic is expressed by Daniel Wesemann in a Nov 2009 blog post. Changing passwords regularly does not prevent a breach.
What website administrators can do
Historically, website administrators created rules for the construction of passwords that were based on length and character set used. But as we have seen above, they do not do a good job of protecting the user. An article in the Tech. Rev. Jul 2010 provides a good summary of a paper to be published at USENIX authored by Stuart Schechter et al. to reduce the risk of a dictionary attack by having the website owner ensure that no more than N users have the same password. The test works by using a hash filter called a count-min sketch. By replacing password creation rules with a popularity limit, presumably users will be able to create more memorable passwords without the risk of accidentally creating a password that is vulnerable to a dictionary attack.
The Tech. Rev. article also describes another paper that examines the password policies of 75 websites. The results are quite counterintuitive.
“We find that none of the factors that might require greater security seems a factor. 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. We also examine several factors unrelated to security. We find that sites that accept advertising, purchase adwords, have a revenue opportunity per login, or where the user has choice, tend to have less restrictive policies.
“Our analysis suggests that strong-policy sites do not have greater security needs. Rather, it appears that they are better insulated from the consequences of imposing poor usability decisions on their users. For commercial retailers like Amazon, and advertising supported sites like Facebook, every login event is a revenue opportunity. Anything that interferes with usability affects the business directly. At government sites and universities every login event is, at best, neutral, or, at worst, a cost. The consequences of poor usability decisions are less direct. That simple difference in incentives turns out to be a better predictor of password policy than any security requirement. This in turn suggests that some of stronger policies are needlessly complex: they cause considerable inconvenience for negligible security improvement.”
The description above explains why my bank warns me that I should change my username and password, but doesn’t actually force me to do anything. They want to be helpful, but don’t want to lose me as a customer.
[Update: For more on website security, see this Nov 2010 blog post.]