I am developing a file sharing and hosting service, and right now I don't have any requirements set other then that a password has to be at least 6 characters long. I also accept all characters.

I'm thinking that it should be possible for users to have the freedom of creating their own passwords, whether weak or strong. However if that is a bad thing to allow, I don't know.

I'm not sure if I should add a not so strict requirement that rejects the most obvious bad passwords like:

  • '      '
  • '123456'
  • '!@#$%^'
  • 'password'

Giving the users that much freedom with their password is a really good thing when it comes to UX. But the strength will be compromised with a large portion of users who use a weak password. Dropbox also uses this approach. And I don't think a strength meter is of use when it's actually not enforced.

Is this considered good practice or should I do it differently?

Note: I will also have server security measurements that go against brute force attacks.


As Question Overflow said in the comments:

There are just too many obviously bad passwords to make it a practical thing to implement and it might annoy your users who just want to sign up quickly.

And I agree with that, so I don't think I will be implementing the not so strict requirement what I considered above.

  • 2
    I let users have full freedom to use whatever password they want as long as it meets the minimum length requirement. There are just too many obviously bad passwords to make it a practical thing to implement and it might annoy your users who just want to sign up quickly. A password meter is useful for users who do care about their security. Commented Apr 21, 2014 at 10:12
  • I very much agree with your first point. But most users who use strong passwords already know what a strong password should be like and don't need a strength meter for that. Commented Apr 21, 2014 at 10:33
  • 2
    I'm not sure this question even makes sense for UX. Of course from a UX standpoint, allowing trivial passwords (or login without a password at all, just writing your username) is the most conventient, but only until the user's account gets cracked. If you don't want your users to get angry and run away due to that happening, you really need proper password quality policy, which is a topic for another SE site like security. Without password strength, there is no defense against distributed brute forcing attacks that doesn't also allow attackers to lock out legitimate users. Commented Apr 21, 2014 at 13:49
  • 1
    I agree with @R.. From a UX position, the answer is to let users makeup whatever password they want. This question is better for a security forum. Now, if your question is "what's the best way to indicate that a user's password is good?" that seems like a more UX question
    – Perchik
    Commented Apr 21, 2014 at 14:43
  • 2
    "I don't think a strength meter is of use when it's actually not enforced" -- A strength meter isn't about enforcing strong passwords, it's about educating the user about what a strong password is. If the user enters 123456 as his or her password, sees that it's weak, and wants to use it anyway, that's their prerogative.
    – Brian S
    Commented Apr 21, 2014 at 15:49

4 Answers 4


I'm pretty sure you have seen this:

xkcd comic "Password Strength"

Source: http://xkcd.com/936/

In other words: Length alone can be good enough as security requirement.

  • +1. I have, but did not pay attention to it until now because I'm not a fan of the style. Commented Apr 21, 2014 at 12:34
  • 1
    There was a paper that showed that if you actually use a grammatically correct english sentence the search space is small enough that you can crack sentences with 20 letters (or something like that). So it's not that clear cut. But in practice probably still better than what your usual user would pick otherwise.
    – Voo
    Commented Apr 21, 2014 at 13:41
  • @Voo: Your comment has nothing to do with the 'xkcd method' which is NOT about choosing a memorable phrase yourself, but choosing four words at random to make a password. Likewise, this answer is wrong (misinterpreting the comic); length does not contribute to password quality whatsoever. Commented Apr 21, 2014 at 13:46
  • @R. Rereading it, you're absolutely right, some parts of my answer were purely in my head. My comment was only about length alone can be good enough as security requirement not about the "xkcd method". Should I delete the comment to not confuse other people or would that be in bad taste to hide "evidence" after being called out on it?
    – Voo
    Commented Apr 21, 2014 at 14:06
  • 2
    I guess this is a good read, related to @Voo's comment and "Length alone can be good enough as security requirement": Grammar badness makes cracking harder the long password: "The result: it was much more efficient at cracking passphrases such as "abiggerbetter password" or "thecommunistfairy" because they followed commonly used grammatical rules [...]"
    – Arjan
    Commented Apr 21, 2014 at 14:49

This is a little bit of a self-plug, but at the same time, this is a piece of user-experience that I care a lot about.

Taking the XKCD approach, we need to reward users for using complex passwords, and educate them to use more complex passwords. When I talk about complexity, I specifically mean the computational complexity behind attacking it, so "correcthorsebatterystaple" is more complex than "Tr0ub4dor&3".

Ultimately we're trying to protect users passwords from being cracked should the password hash database be used, and so along with the normal hashing+salting considerations, we should also be enforcing complex passwords in terms of computation, not in terms of human-intuitive complexity.

I developed a jQuery plugin, Complexify that does this. The basic idea is to look at the character sets that would be required to brute-force the password, and look at the sizes of them, calculating the number of possible passwords over the length of the password being tested. This means that "Tr0ub4dor&3" scores 40%, and fails the check, but "correcthorsebatterystaple" scores 68% and passes. For scoring, the 100% mark is placed at approximately a 28 character password containing uppercase, lowercase, punctuation and numbers.

By showing a 'progress bar' to the user that updates on every key press, they can see what effect different characters have on their password, and see that most of the complexity comes from extending the length of their password.

I would recommend this approach. While my original is a jQuery plugin, there's also now a Node.js version and an Objective-C version. It's a relatively simple piece of code, so shouldn't take more than an hour to implement in most other languages if those aren't appropriate.

  • 2
    The plugin doesn't seem to take dictionary attacks together with grammatical analysis into account. 'mX/%S" (7 random printable ASCII characters) is definitely stronger than What a n1c3 day. despite the second one being more than double the size.
    – Voo
    Commented Apr 21, 2014 at 14:02
  • 1
    @Voo I'm not sure this is true. 7 random ASCII characters might be more secure than an 8-9 character word with some replacements made, but with a string twice as long, there are so many possibilities for words and replacements that I suspect the complexity is comparable if not better.
    – danpalmer
    Commented Apr 22, 2014 at 10:45
  • That said, you're right, the plugin doesn't take into account dictionary attacks because it's just not feasible. However I think basing analysis in the computational complexity rather than in human perceived complexity is still a superior method, and also aids in educating users about strong passwords.
    – danpalmer
    Commented Apr 22, 2014 at 10:46
  • 1
    If it were 4 randomly chosen dictionary words you'd be absolutely right. The problem arises from the fact that it's an grammatically correct sentence (and just trivial replacements), which constrains the search space immensely. And yes you can teach a computer those rules. Although I think most popular tools don't have them built-in so far.
    – Voo
    Commented Apr 22, 2014 at 14:26
  • Fair enough, you may be right. But I still think that an approach based on computational complexity, even if it doesn't account for grammatical analysis, is better than "does it have a number in it". If you have any ideas about implementing some measure of grammatical analysis that could improve the algorithm, please do open a GitHub issue, would be great to discuss it!
    – danpalmer
    Commented Apr 22, 2014 at 14:57

I wearied of the memory burden of passwords for everything and started using a password locker (KeyPassX in particular (not great but sufficient)).

Because I use its random password generation feature, I have quite literally never seen nor typed many of the passwords that I use.

The UX problem that I now bump into is "you didn't follow our arbitrary rules for strength and therefore we reject your password". The "8–15 character" limit is the one that is the most irritating because it forces me to use a shorter password than I prefer.

So please don't restrict my password. You can't guess my security concerns, and if I want to use password your site can't teach me better practices. The best it will teach me that I have to use a hard to remember password, so I'll write it down or forget it. If I forget it, I may not come back to your site out of frustration.

As with every security concern, you have to determine what threat you are protecting against.

  • Only restriction is within 6 to 128 characters. Commented May 13, 2014 at 14:07

In my opinion, it would be a good way to do because although it lets a lot of freedom to your users, it won't expose them to the attacks that are using the most frequent and obvious passwords.

You could also try to detect passwords like dates of birth, phone numbers etc... but for these sort of passwords, you should simply display a warning (because sometimes, even if it's not a very good password, your users might choose an other one that might be even worse if you constrain them too much.

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.