Studies show that people can use some really "insecure" passwords. Here's Mashables worst 25 passwords of 2011 for example. To protect security on our sites (and the overall experience of less-hacked site), can we reasonably disallow common passwords such as appear on this list? Or, would users who want to use "qwerty" as their password be inconvenienced enough that it's not worth it?

Consider these two case studies and answer for both:

  1. personal security— the site retains personal information such as name, birthdate, and email (enough to spam, phish, and mess with users' credit)

  2. financial security— the site retains financial information such as credit card number (enough to rob users and completely discredit the website)

Any studies on password requirements, usability, and user experience would be great.

  • I'm not sure the answers so far consider security as closely as they should, so I've asked a similar question on security.se: Are common passwords at particular risk?. I DO believe common passwords are at a significantly greater risk than other weak but not common passwords.
    – Zelda
    Commented May 22, 2012 at 12:38
  • 1
    Have you considered the level of security actually needed on the product? If it didn't hold any confidential data you could get away with more relaxed password rules; and stricter rules if it does. I agree with what @GotDibbs says.
    – Wander
    Commented May 22, 2012 at 14:55
  • Good questions. For the sake of making this a good SE question, I will modify.
    – Taj Moore
    Commented May 22, 2012 at 15:00
  • The strength indicators don't answer the stated question here, but they are a great suggestion for future development of our systems.
    – Taj Moore
    Commented May 22, 2012 at 15:09
  • 1
    I am not sure this is a UX question. The real question is the business considerations. If your site/app can contain sensitive information or you could be sued if insecure accounts are hacked then the answer should be yes. If the site/app doesn't contain any sensitive information and the user insists on a week password (despite warnings) then perhaps the answer could be no. Commented May 22, 2012 at 16:11

4 Answers 4


I don't think there is anything wrong with disallowing those common passwords, I just wouldn't advertise that you do so if it's a web-app as then a potential cracker would take those rules into account when trying to crack accounts.

What you'll find is that no matter the rules you try to put into place, users who don't care about the information their password is protecting will attempt to find the easiest way around those rules. If you make it so they can't use p@ssword, they'll use p@ssword1. Consider this paper by Dr. Rick Smith entitled "The Password Dilemma". The main sections to read there for this question would be the first three: "Strong Password Policies", "Passwords and Usability", and "Dictionary Attacks and Password Strength".

My opinion is that most people will consider financial information needing to be more secure and the user will therefore be more invested in making a strong password. However, attempting to help a user make their password stronger by providing the appropriate nudge/pressure to make it more secure is not a bad consideration either.

I think the most common practice to help promote stronger passwords is to provide a weak - medium - strong indicator for password "strength". This will allow you to educate your users as opposed to enforcing strict rules which may then be able to be learned by crackers to narrow their search. This meter concept is an arbitrary measure intended to make the user think for a moment longer about their choice of password. A sample methodology for implementing a password-strength meter is provided in this paper "Adaptive Password-Strength Meters from Markov Models".

There's some great information on the usability of passwords on baekdal.com, specifically on how they're most typically cracked.

There are a lot of studies, articles, posts, et cetera on the matter of password strength and usability. With all the above considered, I haven't personally found anything on specifically discriminating on a list of common passwords.

  • 1
    The research you point out is very helpful. The question of "disallowing" weak passwords is covered in the strength meter.
    – Taj Moore
    Commented May 22, 2012 at 17:18

At first, banning simple passwords sounds like a good idea. Though when you look at the implementation methods, none look good:

  1. Server-side: the person fills out & submits the registration form, then receives the error message on reload. Tries a different simple password and receives another error message on reload. Even if you provide them with a list of banned passwords, such an experience is rather frustrating.

  2. Client-side (JS loaded with the page): the user fills out the password field & receives a real-time notification on blur. S/he may try another simple password or just add a simple character at the end to "shut it up". In the end, the password strength issue isn't resolved.

Instead, you should show your users that their passwords are weak with the help of a password meter, which is a proven method to increase password strength. The recent paper Influencing User Password Choice Through Peer Pressure (December 2011) investigated whether peer-pressure indicators (e.g., "Your password is weaker than X% of users") would be more effective than password meters. The results were inconclusive between the two methods of influencing password strength but both methods showed statistically significant improvement over no indicators at all (see Section 4 starting on pg. 39 of the report - (pg 52 of the actual PDF)).

In terms of specific password meters, Dropbox's zxcvbn (GitHub). It's based on complex entropy calculations that are explained in detail in their tech blog and the famous xckd comic about correct horse battery staple.

  • 1
    Actually password strength is pretty significantly improved by ont using one of the most common ones, it's very easy to enter "password" "password1" ect even if there's a rate-limited entry. Brute forcing is generally unfeasible with rate limiting on, but guessing the 1-3 or more most common passwords can often be possible
    – Zelda
    Commented May 22, 2012 at 12:27
  • Indeed, that finding is significant. My point is that there's already a study on what influences an increase in password strength.
    – dnbrv
    Commented May 22, 2012 at 12:45
  • That study is a great find. Now all we need is a study that compares all the various password strength guides/enforcements to see which one produces the most secure passwords (that's probably asking too much though!)
    – JonW
    Commented May 22, 2012 at 16:13
  • 2
    @JonW We need to find a security company willing to sponsor it and then publish it to the community blog. :-)
    – dnbrv
    Commented May 22, 2012 at 16:25

If you're trying to prevent basic, 'manual' abuse - i.e. John sits down at his desk and tries to login to Alice's account by guessing her password - then by all means go ahead and disallow the top 25. If you're trying to protect against more serious hacking attempts, be under no illusions that this will achieve anything. A dictionary attack doesn't discriminate between any two single-word passwords, nor - for most - the standard 'replace letter i with digit 1' obfuscations. If you really want to do your users a favour, set a reasonable minimum length (at least 14 characters) and do not enforce a maximum. There is no reason to enforce a maximum password length (apart from what can reasonably be transmitted over the network), since passwords should be 1-way encrypted before being stored anyway.


By default, I wouldn't disallow the common passwords, but I would put a strength indicator to give to the users a clear feedback on how ‘secure ‘ is their password. Bear in mind that a password is a personal choice, and unless you make clear for them, the users have the right to choose any password.

Have said that, you should understand that this is not only a UX matter, but an IA matter too. Why do you need the password? What kind of information this password will allow the users to access? Do you have a user hierarchy? Who can access sensitive information? And so on. Once you have these clear, you can make a decision on how to handle the user passwords.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.