So Cisco and Meraki are both supposedly "Security Companies"... how on gods earth can you then launch a new Forum/Community with a password complexity policy that doen't allow special characters? sorry, but I find this very ironic...
I'm going to say that this is probably a limitation from "Lithium". However, it is extremely ironic and should be a simple feature to include. I'm also stunned how this was not taken into consideration from get go.
I do find that not allowing special characters is unusual, but they don't make a password more secure. making the password longer is the best options. if the db of stored passwords is compromised and encryption keys stollen, key logger, etc then neither are relevant really. the idea of having a 'strong' password I think is a myth. If you think of it, emails are also part of your password and should be unique as well. when a site has been compromised and emails and passwords obtained, as the owner of this info I can now use your email and password on all of the most popular sites to see if I get a match. Keeping your emails, username and passwords unique increase the likely hood that credential from one site can be used on another.
I later checked my cisco pwd and it does contain special characters so I'm curious to know if this is just for new accounts being created. I've had mine since 2014-11-01
I disagree with nearly everything you say.
I've written several password breaking tools for Cisco products:
The larger the source pool of characters that the password is drawn from the more time it requires to crack. An 8 character password that consists of only letters (and where this is known) is considerably faster to crack than an 8 character password that consists of letters, numbers and special symbols.
Any modern password system does not store passwords in an easily reversible manner. Having the crypted version of the password is just the starting point of breaking the password. The more complex the password set of charcaters the more time it takes to break the crypted text. A long strong password combined with a good algorithm can be impractical to crack because of the huge amounts of CPU time involved. Pretty much if the algorithm requires more than 1000 years of computing time on high end distributed kit you are pretty safe.
I do agree that if the unencrypted passwords are captured by a key logger then you are screwed. You need two factor authentication to mitigate that threat.
of course when you look at brute forcing a password, 8 characters of more symbols available reduces the time to crack that. you're only thinking of this technical aspect though. the most recent nist recommendations also support removing the complexity component and enforcing more length along with a list of known bad passwords list. and remember that most 2fa isn't really secure as it's mostly defaulting to sms or not allowing sms to be removed.
One of the main points about increasing password length is how much easier is it for people to use and remember longer password. As per this study, a "comprehensive8" policy is the most challenging and also most likely to be written down on paper.
Study participants experienced the most difficulty with the comprehensive8 requirements from beginning to end. Only 17.7 percent were able to create a password that met all of the requirements in the first try, compared to well over 50 percent for the rest of the conditions. Twenty-five percent of comprehensive8 testers gave up before they could even make a password that satisfied the requirements, compared to 18.3 percent or less for other conditions. Over 50 percent of comprehensive8 participants stored their password either on paper or electronically, compared to 33 percent for those with the 16-character minimum and less for the rest of the conditions.
when requiring these special characters and complex passwords, sites reveal how I'd go about building a smarter algorithm to crack these passwords. when listing the requirements like the cisco site does ( 1 uppercase, 1 lowercase, 1 number, 8 to 60 characters, english characters: A-z, 0-9, @, -, _, or ., cannot match your email address or User ID) I now can limit the scope of my brute force attack massively reducing the time it takes to go through the initial list of all possible combinations.
having a unique email/username to every site absolutely adds to the security. if I had my email and password stolen from a site not using modern password system, and let's be honest, not many do, having a unique email/username on every other site means I can't take those known credentials I now know and now use them on another site.
as you mentioned, having a larger pool of character as part of the potential options absolutely adds to the strength. this is why all unicode characters (160k+) should be supported and then a 4 character password takes drastically longer having ~6.5E+20 permutations than the 8 character upper/lower/number/special combination typically having just a pool of 95 characters with just ~4.90E+15 permutations.
I'd feel more secure knowing my password in 1111111111111111111111111111111111111111111111111111111111111111 compared to (n4k7#L! any
I completely agree with PhilipDath... If you have a X character long password without special characters and one without special characters the time to brute force is significantly longer... This is true for 8 characters passwords as for 1000 characters passwords.. hence no reason what so ever to not allow special characters.
I see the point if a website puts a limit to number of special characters, and furthermore tells the user the limits, but I have never seen such a site, and it hasn't got anything to do with my original post.
I don't use the same password anywhere, I generate a new one for each site, and by default a newly generated password contains special characters - at least for me....
hehe, I'm not assuming anything... it seem you are arguing for the sake of the argument, not the actual content.
Listen, don't talk about limited charsets during brute force, this is something you brought up, just acknowledge the fact that the number of possible chars a user can choose from when setting a password without special characters is smaller than the number of possible chars a user can choose from when allowing special characters - this is simply the only point I'm highlighting in this post, together with the fact that Cisco and Meraki should know better..
i'm not arguing just to argue, i'm trying to provide a view that isn't often discussed or considered on how usernames and credentials can be made more secure which is the root of the whole post, making a users login harder to know.
of course the more entropy you add to a password makes it harder to guess, i've never said otherwise in any of my statements. what i'm trying to say is that allowing special characters is not the only way to make a login more secure and shouldn't be considered a requirement.