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.
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.
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)
PS: You also forgot about the special character.
"correcthorsebatterystaple" is ok, "correct! horse battery Σtaple" is better.
Why are you arguing i shouldn't be allowed to use any key on my keyboard?
There is no reason to disallow any character in a password. let me use them all. limiting to A-Za-z0-9 is goofy and antiquated.
"better" is a dangerous term. Better as for bruteforce guessing resilience? Sure. Better for security? That would be much less certain. Once you discover the users can't enter it on mobile (no Σ on default keyboard) you'd have to provide replacement mechanism for them or allow them to easily reset passwords. Which probably would be the way your security will be compromised soon. And, of course, the users will be losing such fancy passwords at incredible rates, which would generate a lot of noise on "password reset" system which would make it harder for you to detect abuse there. And that not even considering that humans are very bad at avoiding biases and choosing "random" character replacements - they probably would do the same thing in 90% of cases (yes, you are in the 10% of course, but that doesn't change the statistics), like replacing o with 0 and adding ! at the end. Which robots would defeat instantly.
So it's not about forbidding you from using your special characters. It's that using them - on the whole, not for you personally - may not make any improvement, and if you force it, might actually make the matters worse. Encouraging long passwords that one can remember would seems to be actually better. Or doing away with passwords and using something else :)
Anyway.
Yeah, hopefully we'll come up with something other than passwords.
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.
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.
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.
After looking at lists of user passwords <yes>.
User chosen passwords are generally terrible. If you want users to use secure passwords the correct solution is to generate them and send them to users. Granted, users are going to just write them down at that point.
What lists of user passwords were you looking at? I looked through the default one used by John the Ripper (though they recommend using a larger one for any real purpose) and there were hardly any uses of punctuation at all (exceptions "iloveyou!" and "!@#$%^&*") so I can't make the least bit of conclusions. Reading the list of rules it uses to modify passwords, it prepends and appends digits and punctuation but doesn't seem to delete two characters and then replace them with 1!, or anything similar to that. (Though I'll admit to being inexpert at reading the rule formats and not understanding some). That's as close to empirical data as I've got this side of thinking about how I incorporate symbols and numbers.
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.
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/ ("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
Of course this won't work for sites that restrict the length of a password, or that require special characters.
Ars Technica published an article a few years ago about password crackers, and one of the subjects they interviewed mentioned the XKCD strip in an offhand remark that was flawed and hinted towards what was probably a poor understanding of the subject matter.
Now whenever the XKCD strip is brought up, people who've been shown the article make an appearance and and talk about the scheme being vulnerable while using the phrase "dictionary attack" in a non-specific sort of way.
That's probably what's going on in the GP comment.
http://arstechnica.com/security/2013/05/how-crackers-make-mi...
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.
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.
> For one thing technicaly "w" isn't a latin letter.
Don't be silly. Yes, I know how Romans pronounced 'ave'.