5 ms·
Every extra supported character makes the solution space much bigger. with 2 character passwords, your set is 3844 combinations. If you can manage to add in "!@
by jfoutz 11y ago
Every extra supported character makes the solution space much bigger. with 2 character passwords, your set is 3844 combinations. If you can manage to add in "!@#$%^&*()", that goes up to 5184, a 16% increase in options leads to a 34% increase in search space.
No, it's not necessary, unbounded length is probably better. But it's pretty nice to have a lot more characters, and ought to be an easy win.
- Retric 11y agoEvery required charter type makes the search space dramatically smaller. https://xkcd.com/936/ https://xkcd.com/936/ The goal should be long easy to type and remember passwords, adding an extra few digit is worth far more than forcing passwords to look like: 2K#@1j* Compare say a 20 digit numeric password vs an 9 digit [0-9] [a-z] [A-Z] and special.
- jfoutz 11y agoI'm not saying require *, I'm saying allow the option.
- tgb 11y ago> Every required charter type makes the search space dramatically smaller. That is neither what the parent suggested nor really true. The space of, say, 8 character passwords A-Za-z0-9 that DO have at least one digit is very similar in size to the space of passwords maybe not containing digits. (The latter is 36^8 the former is 36^8-26^8, a reduction by less than 8% of the password space. The difference is even less important for longer passwords)
- Retric 11y agoPeople have a huge bias to add digits and special Characters at the end of a password and start a password with an upper case letter. 1! is also really common. So, the rules often end up with something like a ~90% reduction in search space. PS: You also forgot about the special character.
- tgb 11y agoFor requiring both a number and a special character (out of 10 possibilities): reduces passwords from 46^8 to 46^8 - (36^8 + 36^8-26^8) which is a 27% reduction in password space. I wouldn't call that dramatic and it reduces in importance as the password length grows and, as you bring up biases, it eliminates the most abused password types. I don't understand your comments about adding digits and special characters at the end of the password. password + digit + special character is strictly harder to guess than just password (we've added two extra characters, after all). Do you mean that people routinely delete the last two letters of their alphabetic password and replace them with 1! ? I find that implausible. The key point is that if you don't require numbers and special characters then no one uses them at all so the possibility space becomes 26^8.
- Retric 11y ago> (we've added two extra characters, after all) No, the same length just with more restrictions. Your suggesting you replace a min 8 digit password with a minimum 10 digit password but the gain is from adding length not restrictions. Sadly plenty of passwords are fixed at 8 digits and they reduce the search space below that. So you go from 26^8 to 26^1 x 26^5 and 1! which effectively is just 26^6. IMO it's reasonable to remove the top 100 or so passwords. But, after that your just reducing the search space.
- tgb 11y agoDo you honestly think that people pick MORE predictable passwords when required to include digits and symbols? I agree that few are very creative with how they use the digits and symbols, but in no way is this lack of creativity greater than the lack of creativity that is exercised when given no constraints. People just love to use a dictionary word or common phrase or ncc1701 as their password and call it done. 100 passwords is nothing compared to a state space of 36^8 = 2.8x10^12. Remove a million or ten if you want. I think you're strongly underestimating how large this space is. Almost any change you can imagine pushes people out of the relatively minuscule space of actually-used-passwords and into the vast barren lands of all-possible-passwords and thereby increases time taken to crack. If you think requiring a number and special character are damaging (since people just have them at the end), then how about the requirement that they have numbers and special characters that are NOT at the end? I've seen this before and it forced me to invent a new password instead of reusing one. It's technically reducing the state space, but it increases the space of passwords that are actually used. Sure, those 27% of people who actually generated a random password and then happened to get no numbers or special characters are annoyed that they have to generate a new password, but everyone else is picking better passwords.
- Ntrails 11y agoUsability is key. Once you hit 12+ characters it is extremely likely that the password is vulnerable to dictionary/phrase attacks combining whole words - or you're using a password manager. The xkcd is funny - but it's also a terrible password suggestion.
- Retric 11y agoNothing is wrong with a good password manager. Don't forget having lot's of passwords written down in an office setting is terrible for different reasons. &$RGJL__"LKHF#3fghu seems great until it's an a sticky or notepad file.
- JoeAltmaier 11y agoI just wish the managers would really manage. Instead of just being a sticky-note substitute, if they'd take passwords out of my way (by automatically providing them when needed, once I'm authenticated to the password manager).
- _kst_ 11y agoWhy is it terrible? Certainly a passphrase consisting of 4 English words is going to be easier to attack than a password consisting of a similar number of random letters. But as long as you judge a password or passphrase by its information content rather than by its length, xkcd-style passphrases can be just as good as random letters, but are likely to be easier to remember. Plug: I've written a random passphrase generator, inspired by xkcd's https://xkcd.com/936/ https://xkcd.com/936/ ("correct horse battery staple") that picks random words from a dictionary, subject to requirements you can give on the command line. It optionally tells you how much randomness is contained in the generated passphrase (assuming the attacker knows the parameters you used). Sample output (picking 4 words of 6 to 8 letters): $ gen-passphrase -v 4 6 8 verity nonfat shunted specking 27405**4 5.6405e17 possibilities, equivalent to: 58.97 random bits 12.55 random lowercase letters 9.90 random mixed-case alphanumerics 9.00 random printable ASCII characters The reported numbers will vary depending on which dictionary you use (/usr/share/dict/words by default). In this case, the dictionary contained 27405 words of 6 to 8 letters. https://github.com/Keith-S-Thompson/random-passwords https://github.com/Keith-S-Thompson/random-passwords Of course this won't work for sites that restrict the length of a password, or that require special characters.
- ghayes 11y agoEasy is relative to the experience. If we're talking (26+26+10)^100 versus (26+26+10+10)^100, the difference is moot in terms of brute-forcing the password. However, the inability to double click select, to paste in to chat rooms, etc may change based on which characters are allowed. These properties may be desired (or not) for your organization.
- lmm 11y agoIt's not an easy win compared to just adding more length. Yes adding those characters to the set would increase the search space by 34%, but going from 2 characters to 3 (with the original set) would increase it by 6100%.