Wednesday, October 07, 2009

All about Website Password Policies

Passwords are the most common way for people to prove to a website that they are who they say they are, as they should be the only ones who know what it is. That is of course unless they share it with someone else, somebody steals it, or even possibly guesses it. This identity verification process is more commonly know as “authentication.” There are three ways to perform authentication:
  1. Something you have (physical keycard, USB stick, etc.) or have access to (email, SMS, fax, etc.)
  2. Something you are (fingerprint, retina scan, voice recognition, etc.)
  3. Something you know (password or pass-phrase).
The third form of authentication is what most of us are familiar with on the Web. Of course it’s possible to combine more than one of these methods to create systems referred to as two-factor or multi-factor authentication. Multi-factor authentication helps prevent a number of attack techniques including those in which users are tricked into handing over their passwords by a phishing scam. So if logging in to a website or performing sensitive actions requires the physical possession of an authentication device, then it doesn’t matter if the scammer has the password.

Website Password Policy
While the process seems straightforward, organization should never take choosing passwords lightly as it will significantly affect the user experience, customer support volume, and the level of security/fraud. The fact is users will forget their passwords, pick easy passwords, and in all likelihood share them with others (knowingly and unknowingly). Allowing users to choose their password should be considered an opportunity to set the tone for how a website approaches security, which originates from solid business requirements.

Defining an appropriate website password policy is a delicate balancing act between security and ease-of-use. Password policies enforce the minimum bar for password guessability, how often they may be changed, what they can’t be, and so on. For example, if a user could choose a four-character password, and they would if they could, using lower case letters (a through z), an attacker could theoretically try them all (26^4 or 456,976) in roughly 24 hours at only 5 guesses a second. This degree of password guessing, also known as a brute-force attack, is plausible with today’s network and computing power and as a result far too weak by most standards.

On the opposite end of the spectrum, a website could enforce 12-character passwords, that must have upper and lowercase letters, special characters, and be changed every 30 days. This password policy definitely makes passwords harder to guess, but would also likely suffer from a user revolt due to increased password recovery actions, customer support calls, not to mention more passwords written down. Obviously this result defeats the purpose of having passwords to begin with. The goal for a website password policy is finding an acceptable level of security to satisfy users and business requirements.


Length Restrictions
In general practice on the Web, passwords should be no shorter than six characters in length, while systems requiring a higher degree of security consider eight or more advisable. There are some websites that limit the length of passwords that their users may choose. While every piece of user-supplied data should possess a maximum length, this behavior is counter-productive. It’s better to let the user choose their password length, then chop the end to a reasonable size when it’s used or stored. This ensures both password strength and a pleasant user experience.


Character-Set Enforcement
Even with proper length restrictions in place, passwords can often still be guessed in a relatively short amount of time with dictionary-style guessing attacks. To reduce the risk of success, it’s advisable to force the user to add at least one uppercase, number, or special character to their password. This exponentially increases the number of passwords available and reduces the risk of a successful guessing attack. For more secure systems, it’s worth considering enforcing more than one of these options. Again, this requirement is a balancing act between security and ease-of-use.


Simple passwords
If you let them, users will choose the simplest and easiest to remember password they can. This will often be their name (perhaps backwards), username, date of birth, email address, website name, something out of the dictionary, or even “password.” Analysis of leaked Hotmail and MySpace passwords show this to be true. As was the case In just about every case, websites should prevent users from selecting these types of passwords as they are the first targets for attackers. As reader @masterts has wisely said, "I'd gladly take "~7HvRi" over "abc12345", but companies need good monitoring (mitigating controls) to catch the brute force attacks."


Strength Meters
During account registration, password recovery, or password changing processes, modern websites assist users by providing a dynamic visual indication of the strength of their passwords. As the user types in their password, a strength meter dynamically adjusts coinciding with the business requirements of the website. The Microsoft Live sign-up Web page is an excellent example:



Notice how the password recommendations are clearly stated to guide the user to selecting a stronger password. As the password is typed in and grows in strength, the meter adjusts:




There are several freely available JavaScript libraries that developers may use to implement this feature.


Normalization
When passwords are entered, any number of user errors may occur that prevent them from being typed in accurately. The most common reason is “caps lock” being turned on, but whitespace is also problematic as well. The trouble is users tend not to notice because their password is often behind asterix characters that defend against malicious shoulder surfers. As a result, users will mistakenly lock their accounts from too many failed guesses, send in customer support emails, or resort to password recovery. Either way it makes for a poor user experience.

What many websites have done is resort to password normalization functions, meaning they’ll automatically lowercase, remove whitespace, and snip the length of passwords before storing them. Some may argue that doing this counteracts the benefits of character-set enforcement. While this is true, it may be worth the tradeoff when it comes to benefiting the user experience. If passwords are still 6 characters in length and must contain a number, then backed by an acceptable degree of anti-brute force and aging measures, there should certainly be enough strength left in the system to thwart guessing attacks.


Storage (Salting)
Storing passwords is a bit more complicated than it appears as important business decisions need to be made. The decision is, “Should the password be stored encrypted or not?” and there are tradeoffs worth considering. Today’s best-practice standards say that passwords should always be stored in a hash digest form where even the website owner cannot retrieve the plain text version. That way in the event that the database is either digitally or physically stolen, the plain text passwords are not. The drawback to this method is that when users forget their passwords they cannot be recovered to be displayed on screen or emailed to them, a feature websites with less strict security requirements enjoy.

If passwords are to be stored, a digest compare model is preferred. To do this we take the user’s plain text password, append it to a random two-character (or greater) salt value, and then hash digest the pair.

password_hash = digest(password + salt) + salt

The resulting password hash, plus the salt appended to the end in plain text, is what will get stored in the user’s password column of the database. This method has the benefit that even if someone stole the password database they cannot retrieve the passwords -- this was not the case when PerlMonks was hacked. The other benefit, made possible by salting, is that no two passwords will have the same digest. This means that someone with access to the password database can’t tell if more than one user has the same password.


Brute-Force Attacks
There are several types of brute-force password-guessing attacks, each designed to break into user accounts. Sometimes they are conducted manually, but these days most are automated.

1. Vertical Brute-Force: One username, guessing with many passwords. The most common attack technique forced on individual accounts with easy to guess passwords.


2. Horizontal Brute-Force: One password, guessing with many usernames. This is a more common technique on websites with millions of users where a significant percentage of them will have identical passwords.


3. Diagonal Brute-Force: Many usernames, guessing with many passwords. Again, a more common technique on websites with millions of users resulting in a higher chance of success.


4. Three Dimensional Brute-Force: Many usernames, guessing with many passwords while periodically changing IP-addresses and other unique identifiers. Similar to a diagonal brute-force attack, but intended to disguise itself from various anti-brute force measures. Yahoo has been show to have been enduring this for of brute-force attack.


Depending on the type of brute-force attack, there are several mitigation options worth considering, each with its own pros and cons. Selecting the appropriate level of anti-brute-force will definitely affect the overall password policy. For example, a strong anti-brute-force system will slow down guessing attacks to the point where password strength enforcement may not need to be so stringent.

Before anti-brute-force systems are triggered, a threshold needs to be set for failed password attempts. On most Web-enabled systems five, 10, or even 20 guesses is acceptable. It provides the user with enough chances to get their password right in case they forget what it is or typo several times. While 20 attempts may seem like too much room for guessing attacks to succeed, provided password strength enforcement is in place, it really is not.


Aging
Passwords should be periodically changed because the longer they are around, the more likely they are to be guessed. The recommended time between password changes will vary from website to website, anywhere from 30-365 days is typical. For most free websites like WebMail, message boards, or social networks, 365 days or never is reasonably acceptable. For eCommerce websites receiving credit cards, every six months to a year is fine. For higher security needs or an administrator account, 30-90 days is more appropriate. All of these recommendations assume an acceptable password strength policy is being enforced.


For example, let’s say you are enforcing a minimalist six-character password, with one numeric, and no simple passwords allowed. In addition, there is a modest anti-brute-force system feasibly limiting the amount of password guessing attempts an attacker can place on a single account to 50,000 per day (1,500,000 per mo. / 18,000,000 per yr.). That means for an attacker to exhaust just 1% of the possible password combinations, 6^36 (a-z and 0-9) or 2,176,782,336, it would take a little over a year to complete.

The things you have to watch out for with password aging is a little game people play when forced to change passwords. Often when prompted they’ll change their password to something new, then quickly change it back to their old one because it’s easier for them to remember. Obviously this defeats the purpose and benefits of password aging, which has to be compensated for in the system logic.


Minimum Strength Policy
After everything is considered, the following should be considered the absolute minimum standard for a website password policy. If your website requires additional security, these properties can be increased.


Minimum length: six

Choose at least one of the following character-set criteria to enforce:

- Must contain alpha-numeric characters

- Must contain both upper-case and lower-case characters

- Must contain both alpha and special characters


Simple passwords allowed: No

Aging: 365 days

Normalization: yes

Storage: 2-character salted SHA-256 digest



18 comments:

Stephan Wehner said...

You wrote, "Passwords should be periodically changed because the longer they are around, the more likely they are to be guessed."

I thought this was not necessarily helpful. See also the discussion at

http://www.cerias.purdue.edu/site/blog/post/password-change-myths/

Stephan

Jeremiah Grossman said...

@Stephan - Thanks for the comment and the link, a thought provoking read. Unless there is a particular section to which you could refer me, I must stand by my original quote you cited as technically sound.

As something else to consider, Web users tend to use the same password across multiple systems. Should one system be compromised and passwords lost, the users accounts across the other systems become at risk. Password aging helps negate that particular threat to at least some degree.

Another problem is users who share their passwords with "trusted" others, who may save them or share them on at a later time. This risk builds up, and again, password again helps.

I agree that too frequent password aging i annoying and arguably of marginal value, but maintain that some worthwhile value can be gained even if only annually enforced.

JibbaJabber said...

Don't forget about the new logins most sites are using to thwart locally based attacks on networks to 'sniff' the network for logins via HTTP to send them to the bad guys. It was quite silent but the major players (Hotmail, Yahoo, Gmail, Facebook, Myspace, etc...) have been using an AJAX based login for little while to thwart even man-in-the-middle-attacks by asynchronously passing the information through one or several different HTTPS servers with their own SSL certificates that no freely available tool has yet been able to produce a viable way to extract login data from. Interesting huh?
*waits for someone to develop an AJAX sniffer*

Michael Janke said...

If the salts are random, how do you re-associate the salt that you used for a particular password? It seems like you'd have to store it somewhere, and as soon as you do that, you've degraded it's value.

Paul van Woudenberg said...

@ Michael Janke: Bruce Schneier explains this elegantly in "Applied Cryptography":

"To make dictionary attacks less effective, each password, upon initial entry, may be augmented with a t-bit random string called a salt (it alters the “flavor” of the password) before applying the one-way function. Both the hashed password and the salt are recorded in the password file. When the user subsequently enters a password, the system looks up the salt, and applies the one-way function to the entered password, as altered or augmented by the salt. The difficulty of exhaustive search on any particular user’s password is unchanged by salting (since the salt is given in cleartext in the password file); however, salting increases the complexity of a dictionary attack against a large set of passwords simultaneously, by requiring the dictionary to contain 2^t variations of each trial password, implying a larger memory requirement for storing an encrypted dictionary, and correspondingly more time for its preparation. Note that with salting, two users who choose the same password have different entries in the system password file. In some systems, it may be appropriate to use an entity’s userid itself as salt."

Unknown said...

On a rapidly growing number of sites, I'm getting forced to create "security questions" that seems to be intended to increase the level of security. I'm curious on your take on this practice. I have to say as a user, I hate it because the questions are usually limited to those created by the site and involve information that's often possible to get from public records...like Mother's Maiden name . What I've taken to doing for sensitive sites is creating fake answers to these questions and trying to remember the fake answers...which is pretty hard to do.

Jeremiah Grossman said...

@Mark taken from...

http://jeremiahgrossman.blogspot.com/2006/09/5-more-security-tips-for-power-users.html

"Damn those secrets questions!
Everyone eventually forgets a password and needs to regain access to their account. Most password recovery methods are fairly straightforward providing a few different options to verify your identity. The one method that really drives me crazy is the “clever” secret question and answers. There is no friggin’ way I’m giving any website the name of my 3rd grade kindergarten teacher, dog, or high school and certainly not my favorite color. If a breach was to occur, and they do all the time, then I’ve just lost MORE personal information. To circumvent this non-sense, I’ve begun treating secret QnA’s like username/password pairs. Imagine the surprise of the customer support person when I tell them the name of my dog is ji*P5c$r."

Richard Wang - SophosLabs said...

Restricting the length of a password is a technique that should only be used with great care. Simply truncating a password could lead to a dramatically weaker password. Consider, for example, a user who uses a passphrase of 'daffodilsaremyfavoriteflowers'. It would take a brute force attacker a pretty long time to break that even without the use of numbers or special characters. However, if the phrase is truncated to 8 characters 'daffodil' then it is immediately vulnerable to a simple dictionary attack. Personally I would be rather unhappy to discover that my own carefully chosen passwords were silently weakened by the sites I log in to.

Clerkendweller said...

In most cases you should inform users in text what the policy length and character requirements are, and some advice on avoiding re-using, sharing or having simple passwords. Some people advise against stating these policy aspects, but you can usually infer them from things like strength testers, so unless it's a super-critical application (where you aren't just relying on passwords for authentication?), it doesn't really alter the ability of an attacker to work it out.

Anonymous said...

An other awesome article, thank you for sharing it with us

Anonymous said...

Jeremiah, what are you thoughts on the max password length allowed on an ordering site? What's the best practice length?

Also, do you see any implication on publishing password policy, including the max password length allowed, on your website? I went to various sites such as amazon and ebay and realised that max password length is not stated any where on the sites, and trying to understand whether there is a reasoning behind it.

Insights will be appreciated.

Thanks!

Anonymous said...

Could you recommend or provide some freely available JavaScript libraries that developers may use to implement the feature to avoid or better not to allow simple passwords. Thanks in advance.

Jeremiah Grossman said...

@Anonymous 6-8 characters in length as a minimum is good, but as the articles says, heavily dependent upon character-set and number of attempt restrictions. And I'd find nothing wrong with posting of a password policy, provided it is a relatively good one. :)

Mushegh Hakhinian said...

Jeremiah, as always, an interesting read. I would like to get your opinion on length and complexity - a 16 character 'lowercase only' password has about 10 million times more possible values than an 8 character long one forced to contain characters from all 95 symbols on the keyboard. This is more secure not only because is easier to remember, but also most password crackers will not try to guess 16 character-long passwords. Allow me to disagree on password strength-meters - they are harmful. Essentially, the strength meter lets the end user choose the lowest security password that it would accept. 'AAAaaa111!!!' will score as 'Strongest' and ‘ilikereadingblogs’ will score as 'Weak' on most of them. (If interested, more can be found on my company’s blog: here).

Mushegh Hakhinian said...

Jeremiah, as always, an interesting read. I would like to get your opinion on length and complexity - a 16 character 'lowercase only' password has about 10 million times more possible values than an 8 character long one forced to contain characters from all 95 symbols on the keyboard. This is more secure not only because is easier to remember, but also most password crackers will not try to guess 16 character-long passwords. Allow me to disagree on password strength-meters - they are harmful. Essentially, the strength meter lets the end user choose the lowest security password that it would accept. 'AAAaaa111!!!' will score as 'Strongest' and ‘ilikereadingblogs’ will score as 'Weak' on most of them. (If interested, more can be found on my company’s blog: here).

Anonymous said...

Jeremiah,

Regarding this passage:

"It’s better to let the user choose their password length, then chop the end to a reasonable size when it’s used or stored. This ensures both password strength and a pleasant user experience."

Pleasant experience? This is not necessarily so, and I have personal experience to back it up. While in college, I had to come up with a password for an ATM card. The password was 8 characters long (out of a maximum 10, I think), and I wrote it down on the bank's form.

Over the next five years, the local banks in the area merged and/or got acquired. In my last year in college, I found that my ATM password didn't work anymore after exceeding the proverbial three tries.

I went to a branch to get help. The restriction was lifted (so that my old password was still valid) and yet it didn't work.

Nobody could figure out what was going on until someone noticed that I appeared to be punching "too many characters" for my password: the last bank that got acquired (but not my original bank by far) truncated passwords until the 6th place. The new acquiring bank didn't have such a restriction. In essence, over the years my 8-character password had been changed to a 6-character password. I typed my password up to the 6-th place and, voila, it worked.

I lucked out because the person who noticed I had "too many characters" was one of a handful of old bank staff members remaining after the acquisition.

(As to why they didn't clue on to this before, apparently most people created passwords with the minimum, 4-characters, and the issue didn't come up).

Anonymous said...

Server side: bcrypt

If your database is compromised, a salt won't do anything for you. It might take the hacker a few extra hours to crack the system.

Sha1 -> libraries exist of the hashes, you just search for the hash on google and you can find what it means
Sha1 + salt -> not much better. It just takes a lot of generating random strings into a library of hashes. Once you have the library, you can search the DB has vs the library.

Anonymous said...

@Jeremiah, Stephen Wehner is talking about the section of the Purdue page that begins "Now, looking back over those, periodic password changing really only reduces the threats posed by guessing, and by weak cracking attempts. If any of the other attack methods succeed, the password needs to be changed immediately to be protected—a periodic change is likely to be too late to effectively protect the target system. "

The basic argument is that password change policies help, but in the same way that driving with a pillow under your shirt helps in a car crash... it's marginally safer, but distracts you from more effective measures (seatbelts, airbags, defensive driving / password complexity, bruit force mitigation, intrusion detection).