4 ms·
Is there really any need to generate non-alphanumeric passwords as long as they are of sufficient length? Sticking with plain old A-Za-z0-9 seems like it avoid
by alyandon 11y ago
Is there really any need to generate non-alphanumeric passwords as long as they are of sufficient length? Sticking with plain old A-Za-z0-9 seems like it avoids a lot of interop issues.
- Cthulhu_ 11y agoTrue, but I'm also pretty sure that there's no brute force password guess-o-matic that tries every possible UTF-16 character; they too will stick to the default keyboard-entered combinations because there's very few passwords outside of those.
- deleted 11y ago[deleted]
- jfoutz 11y agoEvery 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.
- 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%.
- ajuc 11y agoA-Za-z0-9 != alphanumeric. My alphabet last letter is "ż" not "z". \w = alphanumeric Some people don't even have latin letters on their keyboards by default. And "latin letters" aren't well defined anyway. For one thing technicaly "w" isn't a latin letter. I'm of the opinion that all restrictions on character set in password are unnesessary and harmful. You shouldn't store plain passwords anyway. You shouldn't even pass the plain password from client to server. Why do you care what character set your customer uses? IMHO the main reason to restrict passwords' character set is to annoy users by forcing them to make another variation of their favorite throwaway password for your criticaly important blog comment section.
- falsedan 11y ago> For one thing technicaly "w" isn't a latin letter. Don't be silly. Yes, I know how Romans pronounced 'ave'.
- sugarfactory 11y agoI quite agree. However I have seen a great many registration forms that only accept a short password. If passwords are handled properly there's no reason to limit password length because a password will get converted to a fixed-length string due to hashing before storing it to a database. So I suspect many people prefer storing passwords in plaintext.