Appropriate password requirements for a login (OpenID) service/provider/delegate/thing

Question

This is with regards* to Stack Exchange's upcoming OpenID provider (and in particular, discussion about password requirements).

Currently, password requirements are:

• Must contain 3 of: lower case character, upper case character, number, special character**.
• Cannot contain any public account field.
• Must have at least 8 unique characters.

The rational for the first two I believe is obvious. The last one is to force a certain minimum password entropy, but in a way that can actually be explained to an end user.

I considered a password expiration policy, but discounted it as too intrusive. Users will often use this service as if it were part of the affiliate site, and forcing them to periodically visit it rather than the affiliate site breaks that illusion.

So my question is, are these appropriate password requirements for an OpenID provider; especially one like this which aims for tight integration with 3rd party sites?

_{*And AviD's suggested it.
**Special character is defined as a non-word, non-digit character.}

Answer 1

The proposed restrictions are harmful. These restrictions are overkill. They are bad for usability. As a result, I think they will harm users' security more than they help.

Usability is where it's at. In my opinion, right now the #1 most important factor affecting password security is usability: the extent to which users use the mechanism in a way that is secure. To a first-order approximation, everything you should do should be aimed at increasing usability and increasing the likelihood that users will behave securely. Every time you have a design decision, you should ask yourself: which option is more likely to cause users to behave securely?

I would expect that the complex restrictions you have articulated are, on balance, harmful to the user's security. I think they will decrease security more than they will increase it. Here are my arguments:

• Frustration. One risk is that users will get frustrated or annoyed, give up, and shift to some other OpenID provider that is less securely administered than SO is -- or just stick with their current SO, instead of adopting SO's OpenID provider. That is a net loss for the user's security.

• Making it hard to memorize. If you have unique restrictions that are specific to SO's OpenID provider, this means that the user will have to pick a unique password for your site. This may sound like a positive, but it could equally well be a negative. If the user already has a high-entropy secret, they likely can't use that one, because odds are it won't satisfy SO's restrictions. I suspect this fact increases the likelihood that the user will be forced to write down their SO password somewhere rather than memorizing it.

• Automated password generators. People are, generally speaking, bad at picking unguessable password. To address this, some folks use tools to generate their password for them. Some have even advocated that these tools should be more integrated into everyone's browser and used widely. Right now the biggest barrier to use of automated password generation lies with sites that pick their own special set of restrictions on password. Thus, your proposed set of restrictions will make it hard for people to use automated password generators. That's bad; you want to encourage people to use automated password generators, because automatically generated passwords will be more secure. And you don't want to create barriers to integrated password generators.

So what should you be doing? I have two pieces of high-level advice:

• Start with a threat model. Don't just start making up restrictions and security schemes that sound good. Instead, start by thinking about the threat model. What do you think are the most likely ways that security will fail? Then, when you come up with a new idea, rather than immediately implementing it because it sounds good, analyze how it will affect each of those likely failure modes. Does it, on the whole, significantly reduce the likelihood of the most-likely failure modes? Just as there's no point strengthening the strongest link in a chain, there's often little point in securing against a threat that's not actually very likely.

  I notice that the question describes a security mechanism, but it doesn't describe the threat model, and it doesn't contain analysis. It doesn't state exactly what attack it is aimed at defeating. In the security design space, this is a "bad smell" which often indicates that perhaps more thought may be appropriate.

  For an example of this kind of analysis, you might read this analysis. The paper argues that about 20 bits of entropy are sufficient for web passwords, as long as the password verification software is architected reasonably, and argues that there is little benefit to passwords with higher entropy. See the paper for the detailed analysis. The paper's conclusion states "We conclude that forcing users to choose strong passwords appears misguided"; see the paper for why.

• Cost-benefit analysis. It is important to assess the costs and benefits of the mechanism, and make sure that the costs are justified by the benefits. In this case, the costs are user annoyance. The security benefits of these restrictions, compared to some less strict restrictions, are unclear and probably minor.

  I encourage you to read Cormac Herley's economic analysis of password security. He points out that the advice that security experts give users about passwords is irrational: the costs to users of following that advice (e.g., their time wasted in selecting, memorizing, managing and entering complex passwords) likely exceeds the benefits (in reduced security breaches) by a large margin. He argues that any restriction which consumes more than a few minutes of the user's time per year is almost certainly a net loss, and in practice I suspect it probably needs to be at least an order of magnitude lower than that. Someone asked for data; he has it.

  On a related note, Cormac Herley has also performed a study of the password policies on 75 different websites. He found a broad range of restrictions. He also found that the degree of restrictiveness is not correlated to the security sensitivity of the site, and suggests that "the sites with the most restrictive password policies do not have greater security concerns, they are simply better insulated from the consequences of poor usability." This should make one think twice about the suggestion that stricter password restrictions are better.

If you're looking for more concrete steps you could take to protect your users and increase the likelihood that they pick secure passwords, here are a few ideas you could consider:

• Include a password strength bar. On the form where the user has to pick a password, include some Javascript to provide a dynamically updated bar that shows how strong the user's password is. You can go with red, yellow, green for insecure, borderline, good.

• Include a pre-generated password suggestion. On the form where the user has to pick a password, you could randomly generate a password for them and suggest they use it. Maybe some will use it!

• Help users avoid popular passwords. One recent research paper proposes an interesting idea: they suggest that users should be able to choose any password they want, as long as not too many other users have previously chosen it. Then, they describe how to enforce this policy, without storing passwords in cleartext on the server.

• Use secure, persistent cookies for user authentication. If you reduce the frequency at which users will have to type in passwords, maybe users will be more willing to pick complex passwords of their own accord, and maybe users will be less likely to be fooled by phishing attacks. I suggest that your site set a secure, persistent cookie on the user's browser when the user first logs in. On future visits, if you detect that cookie, immediately treat the user as authenticated and redirect them onto their final destination, with no user interaction required, so that users are logged in without having to type their password.

• Focus more on the password verification step. Why do we want users to pick high-entropy passwords in the first place? What are the attacks we are concerned about? One kind of attack is a targeted attack, where the attacker has a particular username in mind and wants to break into that user's account. Another kind of attack is a broad attack, where the attacker has a ton of usernames and wants to find one, any one, whose password he can guess. What's the biggest threat for the SO OpenID provider? I suspect the one you should worry most about is targeted attacks, because I suspect an attacker is more likely to be motivated to try to break into a moderator or high-ranked user than an average user.

  • Stopping targeted attacks. There are effective ways to prevent targeted attacks on a single user's passphrase. One very simple way is to keep a count of how many incorrect passwords have been entered in the past day or so. If this count goes above some threshold, then you switch to "oh shit, I might be under attack" mode. In that mode, you can require the user to enter a CAPTCHA along with each password, or you can add a delay after each attempt, or rate-limit login attempts, or you can force the user to solve a proof-of-work challenge (e.g., serve the user some Javascript code and force them to do 20 seconds of computation before you'll accept the next password guess), or some subset of these. There are many possible schemes.

  • Stopping broad attacks. If you want to defend against broadscale attacks, e.g., where the attacker tries one password guess against each of tens of thousands of accounts, you'll need different defenses. But there are also schemes for dealing with this problem as well. One potential countermeasure is to keep track of the overall rate of incorrect passwords, and enter "I might be under attack" mode when this rate starts to get high.

  There is a rich literature on defending against these kinds of attacks. Overall, I think you'd be better off making it harder for attackers to mount password-guessing attacks (e.g., making them run slower), rather than imposing additional restrictions on user passwords. I think there's more bang-for-the-buck there.

Answer 2

The question specifically notes a requirement for "tight integration with 3rd party sites". So all the arguments about how unimportant SE accounts are is besides the point.

Also note that no one is forcing anyone to use this particular OpenID service. There are many to choose from. Differentiation on the basis of good security seems like a good idea for an authentication service.

Bad passwords are a huge issue in the world. Users may well reuse the same password elsewhere. Educating users about how to make a good password is a very valuable service to the Internet. The cost to the user of using a good password is small, especially given the convenience of good and secure agents (in browsers or elsewhere) to remember them.

Sites with valuable information like passwords should plan to be compromised, and plan on how to minimize the damage. Even with a good hashing algorithm like bcrypt, passwords with low entropy can be brute-forced. So good passwords remain a good idea.

So what policy is best? We all have opinions, but there is actually data out there. One interesting new paper is Reusable Security: New Paper on Password Security Metrics. (Update:) It notes the importance of checking proposed passwords against a blacklist of common ones (including things like rows of keyboard keys). It also floats the idea of an interesting new password reject function which also suggests modifications of the proposed password that use the user's basic chosen pattern, but make the password more unusual and thus harder to crack:

[first] evaluate the probability of a human generated password by parsing it with a grammar trained on previously disclosed password lists. This allows us to build a more robust reject function compared to a simple blacklist, while attempting to provide the most user freedom possible, given the security constraints of the system, when selecting their passwords.

Based on the above, the proposed policy certainly seem like the kind of pro-security differentiator that I would look for as a 3rd party site interested in adopting the Stack Exchange OpenID provider, if I wanted to lower the risk of passwords being cracked.

(Update:) On the other hand, if your goal is to attract users to your OpenID service, a scheme that is less likely to frustrate them (as D.W. describes) might be a better business decision. Ultimately, your goals are probably diverse, and the tradeoffs are complex.

Answer 3

Complex passwords are often enforced by an organization's IT department to ensure that the user accounts of employees aren't externally compromised. They're also enforced in situations where a user is trusted to have access that could be damaging in the wrong hands.

In this case, neither situation applies. Stack Exchange doesn't store any private data, and regular user accounts can't do any damage. The only case where these password requirements might make sense is if the Stack Exchange systems were compromised, everyone's password hashes were exposed, they could be easily cracked, and users used the passwords elsewhere. No other scenario makes sense - Stack Exchange can throttle brute force attacks; if the login system is compromised password strength is useless; and even if the user's password is compromised, the damage it can do on Stack Exchange is quite limited. So in all cases, Stack Exchange is not affected by the strength of the passwords of their users.

On the flip side, the strong password requirements will likely cause many people to avoid using the service, and stick with their Google or Facebook accounts, both of which have far fewer restrictions on what the password can be.

This is an issue of degree - how secure can you force people to be before they either avoid your service or sabotage your attempts to "secure" them. For example, someone may have a password they would like to use, but it might not have 8 unique characters, so instead they use "Pas$word". Or they make up a password but know that they won't remember it, so they write it down somewhere that anyone that's near them could see it.

To provide some perspective, here's an examination of the password restrictions that the other OpenID providers prominently featured on the Stack Exchange login pages have:

• Google: 8 character minimum, must also not be a "weak" password, though the exact mechanism they use to determine a "weak password" is obscure. ("abcdefgh" and "abcdefg1" are weak, while "Abcdefgh" is sufficiently strong). They do provide a page with tips for a stronger password.

• Yahoo: 6 character minimum. There is a graphic similar to Google's that shows how strong your password is, but nothing prevents the creation of an account with a weak password.

• MyOpenID: 1 character minimum, no other restrictions. Similar to Yahoo, there's a graphic that shows how strong the password is (source code), but nothing prevents the creation of an account with a weak (or even 1 character) password.

• AOL: 6 character minimum, must also not be "too insecure". There is a password strength meter (source code), and it seems that any password that gets a score lower than 34 is considered "too insecure".

• Facebook: 6 character minimum.

Compared with these, the restrictions on the Stack Exchange OpenID password are far stronger. Unnecessarily so, in my opinion, given that the largest pure OpenID provider, MyOpenID, has absolutely no password restrictions at all.

Answer 4

It all depends on context

My baseline advice is:

Do as Google does

Chances are that if they can compromise Google's OpenId security, they won't bother with you. Anything more secure than that needs to be backed up by a very strong added value proposition:

• We want to be more secure than Google because ____________________
• It is more valuable for our users to have a less convenient service than Google, because we offer ______________________ as added value

Secondly I can offer this piece of real data:

10% of users will use the same username and password, as measured on some sites I've built, with 50k-500k users.

E.g. user name Foobar123 and password Foobar123.

More in general, making the password more secure is only actually useful if you are implementing the authentication mechanism correctly:

• User name is not secret but you do not leak whether it exists in your system
• Password is strong enough
• The two pieces of information are completely independent:
  • Different
  • Never stored or sent together (you'll love this—including in other sites where they might be used).

Answer 5

The 8 unique characters is a bit on the excessive side.. Just checked and there are fewer than 1500 words in English dictionaries, with 8 or more letters that are all unique, so what you are also doing is not accepting dictionary words. Not that this is a bad idea, but you could say just that 'dictionary words are not allowed'.

Of course this will frustrate users, and will make many of them type recognizable keyboard patterns, like every letter in a row. Those patterns are there in the dictionaries of every good cracker.

Edit: I couldn't help myself, had to post this here: http://popstrip.com/password-validation/ :-)

Answer 6

I love how we are having this debate still in 2011. I wonder in another 10 years whether we will still be discussing the most appropriate password policy.

I agree with @Kyle-Cronin that the right way to approach this is to examine the risk:

• What is the value? For standard users just the Stack Exchange (SE) account is of low-moderate value. It is not a a throw away subscription, reputation and online profile are important but less so than email, social networks, online banking, payment systems. Moderators could have slightly more value but still not high. An interesting question is raised by @Iszi on whether as a Federated Identity provider if there is a responsibility or duty of care to provide more security than the original site warrants simply because it could be used by more valuable sites. You could rely on the user to set a stronger password if they use SE Open-ID on more valuable sites but this may not happen. Alternatively setting the maximum just in case the ID is used for say Internet banking seems overkill. Arguably these sites would consider the context that SE is used and seem unlikely to offer SE Open-ID therefore they can be discounted. The most likely sites to use the SE Open-ID are social network and start-up sites looking to support a wide variety of federated logins and target the various SE communities as customers.

• Threats and motivations? The main threats for SE accounts are probably spammers. They are motivated but use a dragnet approach seeking the largest possible coverage with the least resistance. Potentially disgruntled or malicious users who want to escalate privileges to moderators, trash other users etc however these would probably not have very high motivation to subvert basic password controls. Social networks and other start-ups that use SE Open-ID are not likely to face highly motivated attackers at least in the beginning. Later if they perceive a higher risk they would probably re-consider their support for SE Open-ID or add additional controls e.g. adaptive authentication or fraud monitoring systems.

• Vulnerabilities? The main attacks that a password policy will defend against is brute forcing or guessing a password. With an exponential back-off or a short account lockout even a 6 character password can provide a reasonable level of difficulty to brute-force or guess. Especially against the type of threats and motivation levels we anticipate. Larger and more complex passwords would really only defend against someone obtaining the full or partial database of passwords. Assuming a reasonable multi round hash and seed method with bcrypt etc as well as a reasonable infrastructure controls this is sufficiently low probability for the SE threats that it is not worth the useability trade-off

• Risk summary: Overall the risk for a standard user is low with a basic set of password policies place. Moderators face a slightly higher risk and users that utilize the SE Open-ID for more sensitive sites face the highest risk of all.

Therefore I suggest a segmented set of password controls to present the best balance of risk and useability:

Standard users:

• Minimum length 6 characters. Even though MyOpenID offers 1 character most users now are used to about a 6 character password and this should not put off many users from joining and using the site and be memorable enough. As stated this is what is used by Facebook and Yahoo
• Show simple password strength indicator updated as they type but do not mandate any further. Encouraging a user to utilize a password vault to generate the password here on the UI is also a good idea
• Exponential back-off 2 seconds on every failed attempt doubling with each failed attempt

Moderators (Additional):

• Must contain 3 of: lower case character, upper case character, number, special characters
• Cannot contain any public account field.
• Minimum password length 8 characters

When a user becomes a moderator they can be prompted to change their password with the new requirements

Authentication for other sites (Additional):

Any user that uses the SE to authenticate to x other sites (x could be configurable 3 is probably a good number when the risk increases to warrant sufficient security). As I don't think there is any good way to judge the risk of the sites SE Open-ID is used for without maintaining a manual list and knowing the users risk profile a basic number of sites linked is sufficient. This should also apply for higher sensitive SE sites like careers.stackoverflow.com as this is storing personally identifiable information.

• Offer a two factor option e.g. SMS on time password, soft token like Google authenticator. Not sure if this could be developed and supported cost effectively by SE

When a user links additional sites they can be prompted to change their password with the new requirements

8 Unique characters is a nightmare for usability and offering two factor would be a lot better option for this risk level. Password expiry also is more detrimental than beneficial so I'm glad that was not proposed.

Answer 7

You should add that:

• No passwords should be their user names (that is just stupid but happens).

• No actual words, or at least a word combination that is not in dictionaries (I learned from a website about cyberspace problems and one of them was about problems. It said that sometimes hackers attack and hack with computers that could find words and then predict your password like that).

• Passwords should also be complex, unique but easy to remember like a sentence with the beginning of each letter somehow changed.

• You could completely not let people finish their sign up process unless they put at least some numbers and a capital letter with some other things, like H3110!:|.

• you could also add a checker to see lets them see their password's strength

• Try adding in 2nd and 3rd passwords with their phone number and other personal things like their thumb print (this is inspired by Google) so that way the hacker has to literally "be" their victim in order to get past.

• Try encrypting their information with another password that just the person knows in case of an hacker ever successfully hacked in, so they can't get through this password either very easily.

• I know this one is going to be hard to add but maybe add an little companion on your website/place/whatever that knows their personality so if it sees a change, it would probably guess it would be a hacker unless the person said so in the first place. Kinda like a personality software for every user (everyone is different after all).

• Also alert them if anyone else besides who they know goes on to their account. If they say they don't know who that person is it is probably a hacker then (Google does this).

• For phishing mails/things/whatever try scanning them first before letting them see it (test if it's safe), them ask them about it, and if they say no, destroy it, preventing them to be tricked by the hacker.