12

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.

EDIT

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.

Community
  • 1
Kid Diamond
  • 414
  • 2
  • 14
  • 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. – Question Overflow Apr 21 '14 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. – Kid Diamond Apr 21 '14 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. – R.. GitHub STOP HELPING ICE Apr 21 '14 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 Apr 21 '14 at 14:43
  • Be super strict! Don't allow any passwords that aren't on a whitelist containing, say, a thousand strong passwords - then no-one will have an easy-to-guess password! – rlms Apr 21 '14 at 14:50
  • 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 Apr 21 '14 at 15:49
  • You may want to consider a class of user who can be trusted to decide (helped by a strength meter). 2 extreme examples: The user wants a temporary online stash of all the photos they've uploaded to wikimedia commons, for easy access (no security requirements to speak of); the user doesn't trust your very much and only uploads encrypted files (OK they may want security from deletion). Either way a weakish but memorable password could be what the user needs. Forcing a strong password is just annoying: I've 1 account where a 5 char dictionary word in my chosen 14 char password blocked it – Chris H Apr 21 '14 at 15:56
  • Related: http://ux.stackexchange.com/q/16433/687 – Danny Varod Apr 21 '14 at 17:56
  • See also https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-strength-estimation/ and http://ux.stackexchange.com/questions/55645/does-a-password-strength-indicator-increase-password-strength – assylias Apr 21 '14 at 18:05

4 Answers4

13

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.

unor
  • 3,956
  • 1
  • 24
  • 47
Jørn E. Angeltveit
  • 12,588
  • 4
  • 41
  • 79
  • +1. I have, but did not pay attention to it until now because I'm not a fan of the style. – Kid Diamond Apr 21 '14 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 Apr 21 '14 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. – R.. GitHub STOP HELPING ICE Apr 21 '14 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 Apr 21 '14 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 Apr 21 '14 at 14:49
  • Here is a complexity comparison I did including multiple password patterns: http://ux.stackexchange.com/a/22886/687 – Danny Varod Apr 21 '14 at 17:59
  • Thank you for the edit, @Arjan. I actually didn't know to include the Alt-text, but you're absolutely right. The xkcd jokes aren't the same without the alt-text ;-) – Jørn E. Angeltveit Apr 22 '14 at 10:19
  • I haven't seen that before. Very interesting! And good to know! – DA01 Apr 22 '14 at 17:36
4

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.

danpalmer
  • 141
  • 2
  • 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 Apr 21 '14 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 Apr 22 '14 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 Apr 22 '14 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 Apr 22 '14 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 Apr 22 '14 at 14:57
  • I'll see if I can find the paper (MIT I think?) where people created rules for popular tools to crack those kind of passwords. That would be a good starting point, not sure how complicated an implementation of this would be (and you'd need an annotated dictionary.. mhm). Tempting to write an algorithm that takes that into account actually. – Voo Apr 22 '14 at 15:16
  • The difficulty here is limited computational power, and the fact that you don't want to distribute a dictionary data set that is too large. Realistically, 10kb is probably a good target for the script. Ideas that have been mentioned before are a serialised bloom filter containing dictionary words I seem to remember it being impractical for some reason though. – danpalmer Apr 25 '14 at 18:08
  • Hmm bloomfilters would have to take care of the usual trivial replacements (e->3) and other canonicalizations beforehand but yes should work. 10kb of data seems quite big anyhow, that should allow you to store the ~2k most used words without any compression to begin with. You'd need different bloomfilters for all different grammar groups though for grammatical analysis to work. Here's the paper btw. – Voo Apr 25 '14 at 18:15
  • Of course, "correcthorsebatterystaple" is given a 68% by your method yet is one of the easiest passwords to crack. Gödel and Epimenides strike again. – msw May 13 '14 at 05:55
1

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.

msw
  • 784
  • 6
  • 8
0

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.

Pop Flamingo
  • 573
  • 2
  • 11