107

I am using an online service that I recently had to reset my password because I forgot it. When I went to change password I wanted to use one with a symbol !@£$%^&*(). When I clicked "confirm password" it displayed "_Invaid Data" to me which I eventually found is because of the symbol. I then spoke to customer services and told them about this (as well as to replace "_Invalid Data" with "Passwords can only contain letters and numbers") and they replied back saying "Sorry, the guidelines we put in is place is for security measures". (This is what the message sounded like to me)

The question is why did they say that its insecure to allow symbols in passwords when symbols make it safer?

To make sure they have better security in the future I did educate them and said that if you have a 8 character long password with letters and numbers only, it would allow for 36^8=2,821,109,907,456 combinations where as including the 12 symbols(!@£$%^&*()_+), it would allow for 48^8=28,179,280,429,056 characters long, meaning there is an extra 25,358,170,521,600 combinations and they are now forwarding this information onto their manager.

iProgram
  • 1,187
  • 3
  • 9
  • 15
  • Just to give a clear answer, did their response literally say passwords are more insecure with a symbol, or is that the way you interpreted their message? And was the message written (email) or verbal? I would assume they have to say it because of a policy, or give a similar answer and they just worded it poorly. The answer is most likely going to be "because that's how it was designed," but there's no way to find that out. The only way to be more secure than their passwords is to make sure your password is unique to that website. – dakre18 Jan 26 '16 at 19:02
  • 88
    Allowing symbols is passwords does increase the search space for passwords and makes them more secure, there's really no reason to disallow them.They may be using the passwords internally and thus need to sanitize them of symbols? But that would indicate other things that you should be worried about such as storing your password in it's plaintext form in a database. – sethmlarson Jan 26 '16 at 19:03
  • @dakre18 As I said, I assumed that is what they were saying, I gave the quote that they sad to me in quotation marks. This was from an online chat. – iProgram Jan 26 '16 at 19:15
  • 3
    @iProgram just wanted to clarify that, but if you hear the same thing from more than 1 customer service rep, it's scripted (obviously at that point), but they won't ever tell you that's how their developers designed it. If they did, it would just cause more problems. – dakre18 Jan 26 '16 at 19:37
  • @dakre18 Think I should try again another time so I know if it is scripted or there is another problem like sanitising data? – iProgram Jan 26 '16 at 19:39
  • @iProgram Wouldn't hurt, however, if it isn't scripted the rep worded it poorly. That can happen if the rep isn't familiar with password security, but worst case it's scripted to avoid reps saying the wrong thing (normally). – dakre18 Jan 26 '16 at 19:56
  • 1
    Troy Hunt has some info on it [here](http://www.troyhunt.com/2011/01/whos-who-of-bad-password-practices.html) and [here](http://www.troyhunt.com/2011/03/3-reasons-youre-forced-into-creating.html) which I think is interesting to read. – jao Jan 26 '16 at 19:57
  • 9
    Nitpicking your math: typically passwords are case sensitive, so only allowing letters and numbers would have 62^8 combinations instead of 36^8. – TTT Jan 26 '16 at 19:59
  • 3
    @TTT Opps! Good spot! – iProgram Jan 26 '16 at 20:01
  • 13
    It's a mistake to think leaving symbols in the character set magically adds security. If you want to increase defenses against brute force password cracking, you are much better off by increasing the minimum password length to 12 or more characters, and by requiring increased complexity including requiring all three types of upper and lower case characters and digits. – John Deters Jan 26 '16 at 20:50
  • 2
    Simple: their programmers actually don't understand what secure coding means and just applied what they saw on a web site somewhere. They then feed a line of BS to the customer support team (who honestly doesn't know anything either). Regarding preventing "sql injection" you'll likely find other text fields on that site that you can absolutely enter those characters in. – NotMe Jan 26 '16 at 21:09
  • @iProgram: "To make sure they have better security in the future I did educate them and said that..." Call me cynical, but I doubt your comments were remembered for more than three seconds after the phone call ended. :-) – loneboat Jan 26 '16 at 22:26
  • 1
    @loneboat This was a online chat. They also said they will forward it on. Wouldn't supplies me if they don't. Mind you, they did call me a genius so they may do. – iProgram Jan 26 '16 at 22:29
  • 3
    Name and shame. I would not choose to do business with anyone who does this. This screams to all engineers "WE STORE PASSWORDS PLAINTEXT". – Joshua Jan 26 '16 at 23:55
  • 12
    Because they're wrong. – DJMcMayhem Jan 27 '16 at 01:59
  • 4
    Important to note - "Sorry, the guidelines we put in is place is for security measures" **does not** mean using symbols is less secure! It means the guidelines they have put in place are for the security measures they have decided are appropriate. You may want them to use stronger security measures, but their risk assessment has given them a position they feel is fine. – Rory Alsop Jan 27 '16 at 09:43
  • 6
    Because one of the them is called Little Bobby Tables and they have learnt their lesson: https://xkcd.com/327/ – Matt Wilko Jan 27 '16 at 10:11
  • 2
    why does every bad password policy question become a hot topic on this site? these are so overdone and the answer is always the same. more entropy, and more randomness = stronger passwords. [Insert XKCD comic here] – n00b Jan 27 '16 at 16:21
  • Why assume that the costumer service person knows why the decision was made? All they know is that the programmers decided to use that policy. – Christian Jan 27 '16 at 22:30
  • 3
    What worries me is, why would the *password* need to go through the database at all? It should be irreversibly hashed well before then. – Niet the Dark Absol Jan 28 '16 at 00:17
  • 3
    Most likely, the answer is that the customer service person didn't know the real reason. As an aside, I'd recommend against using `£` in a password: any time you try to enter that symbol outside the UK, except on your own laptop, you'll find that the key doesn't even exist, so you can't log in. (Of course, if this is the kind of password that you wouldn't dream of typing in except on your own laptop, that's much less of an issue.) – David Richerby Jan 28 '16 at 01:26
  • 1
    @JohnDeters If i know your site only has letter/number passwords i have to go trough so much less combinations to brute force the same length password with characters in it .... So it's not a mistake! – Иво Недев Jan 28 '16 at 14:36
  • Am I the only one who thinks this question sounds like the start of a very lame joke? – corsiKa Jan 28 '16 at 20:30
  • Is there really any valid reason to prohibit the semicolon? I know that some of the responses on here say that they may limit responses so that keyboards will have the characters in the password present, but isn't prohibiting a semicolon indicative of not hashing or sanitizing inputs properly? – John Jan 28 '16 at 23:12
  • 3
    @John Us programmers always hate the semicolon! – iProgram Jan 29 '16 at 10:05
  • 1
    @iProgram Praise Javascript, where the semicolon is optional! – Michael Jan 29 '16 at 19:34
  • One point here - the more onerous the password rules (One uppercase! One lowercase! One number! One 'special'!) the more likely people are to write the password down. There is 'mathematically secure', and there is 'practically secure'. – Tony Ennis Jan 30 '16 at 17:50
  • 1
    ... and/or write it in a predictable manner. When _forced_ to use a "special character" I have witnessed several people just stick a `!` on the end! – MrWhite Feb 01 '16 at 10:04
  • Don't fetishize symbols. Length beats character classes - especially when people only throw in a number of symbol to keep the "password strength meter" happy. A 64bit entropy password could be 20 decimal digits. Lowercase letters and numbers still needs 13 characters to equal it ***and then only if it's random***. Adding a choice of 30 symbols to a 10 character password of random upper/lower/digit is equivalent to making it an 11 character password. In reality the tendancy to choose common sequences of characters means you really need 20 characters **whatever** alphabet you are choosing from. – Ben Feb 01 '16 at 10:13
  • 1
    Just to name and shame because I'm still angry about it - one of Transport for London's public facing Oyster login system requires a password between 8 and 10 characters long, starting with a letter, containing at least one capital, containing at least one number, and containing no symbols. I complained. This is also "for security". – OJFord Feb 01 '16 at 14:23
  • Because they're not parametrizing their SQL queries. – Wayne Werner Feb 01 '16 at 17:34

15 Answers15

209

These 'security measures' aren't for your security, but for theirs.

Symbols like hyphens, apostrophes, percent signs, asterisks, slashes, periods, etc. are useful to attackers for performing "injection" attacks, like SQL Injection, XPath Injection, file path injection, etc. By blocking those characters, the site owners hope that they are preventing you from attacking their servers.

They should probably be focused more on proper data handling, like internally using parameterized SQL and special character escaping, but this is an additional measure that could help serve as a stopgap in case they have a hidden coding error in their site.

I can't definitively answer 'why' they did this. Maybe they had a security auditor who said "use a whitelisted character set for user input, and block any non alphanumeric symbols." Maybe the web package they bought came with that restriction. Maybe their Vice President of Security said "add some visible measures that give our customers the impression that we take security seriously." Who knows why?

John Deters
  • 33,897
  • 3
  • 58
  • 112
  • 42
    I can't definitively answer 'why' someone else does something. Maybe they had a security auditor who said "use a whitelisted character set for user input, and block any non alphanumeric symbols." Maybe the web package they bought came with that restriction. Maybe their Vice President of Security said "add some visible measures that give our customers the impression that we take security seriously." Who knows why? – John Deters Jan 26 '16 at 19:21
  • 195
    Well, strictly speaking, if they were interested in proper data handling, the password wouldn't be in the database to begin with (escaped or no). It'd be hashed, salted... peppered... glazed, broasted, powdered, and finally left to simmer over a low flame for 15 to 20 minutes. – Parthian Shot Jan 26 '16 at 20:28
  • 62
    Mmmm...password hash. Breakfast of champions. :-) – John Deters Jan 26 '16 at 20:42
  • 61
    They're savvy enough to care about SQL injection, but think the solution is to disallow certain characters in users' passwords? I smell a disconnect here, like a security officer somewhere knows just enough to be responsible for--but very careless with--a lot of users' data. – loneboat Jan 26 '16 at 22:29
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/34928/discussion-on-answer-by-john-deters-why-did-customer-services-say-using-symbols). – Jeff Ferland Jan 27 '16 at 17:41
82

The question is why did they say that its insecure to allow symbols in passwords when symbols make it safer?

More than likely you were dealing with someone in customer service that has no clue as to why certain rules were put in place and has come to the conclusion, either through using this excuse in the past and having results or making it up in their head, that this will make the person they are dealing with not question and just do.

Your explanation is right about the complexity of a password becoming greatly more secure by adding in symbols as well as letters, upper and lower case, and numbers.

I would write this off as either an untrained customer service agent just trying to make the job easier or this person knows the policy is flawed and just wants to make this conversation as short as possible.

JohnB
  • 103
  • 4
Eddie Studer
  • 1,049
  • 7
  • 17
  • This seems reasonable and is what I was thinking. – iProgram Jan 26 '16 at 19:24
  • 2
    I know the call takers we have at the company I work for are, in some cases, just following scripts for minor items like this. If it is something bigger and out of the scope they can solve easily then it gets forwarded on to the proper group. – Eddie Studer Jan 26 '16 at 19:37
37

Because they're probably using input sanitation instead of parameterized queries and output sanitation.

If they had parameterized queries, this would not be a problem. If they knew how to sanitize their output, this would not be a problem.

More than likely, their code is vulnerable to a lot of other things, such as unicode-based smuggling. To many "secure developers," input sanitation is simply stripping apostrophes from input, which is an incredibly terrible approach.

This will not protect against unicode-based smuggling, and will interfere with legitimate purposes for apostrophes in a database, such as people's names. Imagine trying to search for someone's last name in a database, but you can't because there's an apostrophe. That's dumb.

The correct solution is as follows: input validation (null > length > format > whitelist) ** > **parameterized queries > output sanitation (to avoid XSS), which they are likely not following. There is no legitimate reason to exclude proper data.

Mark Buffalo
  • 22,508
  • 8
  • 74
  • 91
  • This doesn't sound good. Security should be solved before it is a problem. This sounds more like a bodge then security. – iProgram Jan 26 '16 at 19:38
  • 3
    It's a band-aid. A weird analogy may be, "in order to protect ourselves from bullets, we're going to wear a mirror bodysuit so they don't see us!" You can still shoot the mirror... – Mark Buffalo Jan 26 '16 at 19:43
  • 25
    Worth noting (as @ParthianShot did above) that for a **password** in particular, they should never be attempting to store a password in any way. The un-hashed value of the password shouldn't ever touch their database, or any other similar component. – CBHacking Jan 26 '16 at 20:46
  • @CBHacking Of course. – Mark Buffalo Jan 26 '16 at 20:47
  • @CBHacking I honestly don't know why I'm upvoting your comment when it's ParthianShot's, but the content is so true that here's a +1 anyway. – Joshua Grosso Reinstate CMs Jan 26 '16 at 23:51
  • Now I'm thinking about this, it does seem likely. I may contact customer support again and warn them about it. – iProgram Jan 27 '16 at 10:50
  • Why would you assume they are using input sanitation? I would want to disallow symbols because £ is not universally available on all keyboards. Some users will create a password using £ on a device with the £ symbol and will be locked out on devices without, or they will call support for a reset, or they will call support for education on how to type the £ symbol on their device. The increased password entropy of using the £ symbol is not worth the increased support costs. – emory Jan 27 '16 at 13:22
  • @emory Because input sanitation is still a widely-used practice, and it's terrible. I agree I should've put "probably." However, the scenario where you're using "pound" is easily changeable. I have such a device where I can change my "$" symbol to ¥ very easily with the tap of a button. Most devices purchased in said countries come with the default input set for that country, and is not likely to be affected by your scenario. Even if it was, pound is available by default on my Android keyboard. I've simply never heard of that happening, but I wouldn't be surprised if it has. – Mark Buffalo Jan 27 '16 at 13:42
  • @MarkBuffalo so you switch your $ with your ¥, forget you made the switch, create your password. In your mind it is pa$$word, but in fact it is pa¥¥word (on the screen it is ********). It seems like asking for trouble to me. But I don't have numbers for either how prevalent input sanitation is or how big a problem symbols in passwords are. – emory Jan 27 '16 at 15:30
  • @emory Usually the last character is visible. ;) Anyway, I am not downplaying your concern. I do believe it's valid. – Mark Buffalo Jan 27 '16 at 15:33
  • 1
    I would argue that input sanitization can be a valid part of a defense-in-depth strategy. Consider that the web front end team may not be the same team who wrote the password management app. They may have their own standard calling for all input to be sanitized because they may not trust the back end teams. We can't assume that everyone is always responsible for every aspect of the systems they work on. Or they may be implementing a rule because it's a written part of their security policy (dumb or not, policies still have to be followed.) It's not necessarily a bad omen. – John Deters Jan 27 '16 at 16:22
  • 1
    This really should be the accepted answer. Using input sanitization instead of parameterization for queries is a sign of a database coder who doesn't know what they're doing. – Mason Wheeler Jan 27 '16 at 20:38
  • @JohnDeters What happens when you try to add someone to the database from Ireland? Rory O'Cune becomes Rory OCune. That leads to lots of errors and technical resources being exhausted, on what could've otherwise been a simple, properly-implemented parameterized query. – Mark Buffalo Jan 28 '16 at 18:24
  • 2
    @MarkBuffalo, the easy answer is data integrity is lost, along with a certain measure of reputation with customers whose names are hyphenated or apostrophied. Like anything, it's a risk tradeoff - does your marketing team risk the ire of the entire O'Cune clan and half the residents of Ireland, or does your Info Sec team trust your back-end contract development firm to always use parameterized SQL correctly on every single query, and to sanitize the outputs properly? I know what the Info Sec people would say. – John Deters Jan 29 '16 at 05:45
  • @JohnDeters `"does your marketing team risk the ire of the entire O'Cune clan and half the residents of Ireland"`. LOL! Clearly, I would not trust them unless they completed secure software training and demonstrated understanding of said concepts. At my company, we do this. You are required to learn secure software development practices. :] – Mark Buffalo Jan 29 '16 at 05:48
15

Agree with your analysis that allowing symbols allows for more security, but generally it's not that much. Especially when compared to going to slightly-longer passwords (assuming the password is completely randomly chosen symbols). Using any of the 95 printable ascii characters:

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^_`{|} ~

(a few more if you count characters like tab or linebreak as printable) an 8-character password has 95^8 ~ 6.6 x 10^15 possibilities, while with only (case-sensitive) letters and numbers an 8 character password has 62^8 ~ 2.2 x 10^14 which is about 30 times weaker.

However, a 9-character password with just numbers+lowercase+uppercase is two times stronger than an 8-character password allowing special characters. Thus, unless there are hard limits on the length of a password (and really there never need to be at least for passwords less than a few hundred characters), it is easy to move to slightly longer passwords even with a limited character set.

The biggest potential security concerns is if they believe allowing special characters in passwords could cause problems in their application or database. There is a legitimate reason to exclude non-printable ASCII characters (e.g., ASCII control characters NUL (\0), backspace (\b), etc.) that could cause problems, but well-designed applications should be able to handle regular special characters like ' or - without being vulnerable to injection attacks. An application should be able to handle these types of characters as they appear for example in names with quotes or hyphens in them (e.g., Conan O'Brien, Daniel Day-Lewis). Furthermore, as passwords shouldn't be saved to the database or ever given back to the user and just immediately hashed, allowing printable ASCII special characters shouldn't matter.

Granted there are some usability concerns with non-ASCII special characters like unicode, and for usability concerns it may be a good idea to either forbid these characters or normalize them in a standard way. Hash functions typically expect a string of bytes, and passwords with special characters beyond ASCII can be encoded in different ways at the byte level (e.g., UTF-8, UTF-7, UTF-16, ISO-8859-1). Furthermore, besides different encodings (which you could keep consistent at the application level), you also have to worry about identical looking letters having different values in unicode. For example the following character Å is unicode 00C5, but this identically looking character is Å unicode 212B while this Å is actually two characters -- an ascii A with a combining character of unicode 030a adding a circle over the A.

EDIT:I just noticed you listed £ as one of your common symbol. Unfortunately that's not a standard ASCII symbol. In ISO-Latin-1, it's the byte A3. In UTF-8 it's the two bytes C2 A3. In UTF-7 it's the ASCII characters +AKM-. In UTF-16 it's 00 A3. These different encodings mean that your hash function may break on this character if it's not handled properly. Granted, the application should be able to handle encoding properly, but it could fail on some subset of devices. Furthermore, the character may not be available on foreign keyboards.

There also may be usability issues with characters like ' or " that in some applications/platforms may be converted to smart quotes ‘’“” (though this should never be done in a password context).

Finally, there's one additional rational for having unique password rules -- make it harder for users to have one remembered password that is re-used everywhere, which is a horrific security practice. If the user's "normal" password doesn't meet one site's unique rules, then when their normal password is compromised on some random other site (that say stores the password in plaintext), their account isn't compromised at the site with the unique rules.

dr jimbob
  • 38,936
  • 8
  • 92
  • 162
  • 2
    I personally prefer using longer passwords chosen from a smaller alphabet. Anywhere I can get away with it, I stick to only alphanumeric characters in my passwords. Even if you went from the entire range of printable ASCII characters to only lower case letters, it just means you need a 40% longer password to have as many possible passwords. – kasperd Jan 26 '16 at 21:39
  • 2
    Smart quotes can bite someone if they're trying to keep track of passwords in a document produced by a word processor application that likes to convert the ASCII apostrophe and quote characters into the "smart quote" equivalents. Of course, they ought not to be using such applications for that purpose, but nevertheless they do. So I would not object to excluding them, as well as backquote. – Monty Harder Jan 26 '16 at 22:27
13

A bit long fetched but…

Say, John’s mother gets given a IPad for Christmas, she then decided to log into her bank using it (rather than her laptop), but can’t work out how to “type” the symbol on the IPad. So she asks someone to show her how to type her password…..

Now think about the support issues with customers having passwords they don’t know how to “type” on their phones or tablets. Lot of support calls asking for passwords to be reset is an security issue as well as a cost issue.

Ian Ringrose
  • 641
  • 1
  • 4
  • 10
  • 3
    Hence why you have a "forgot password" link on your webpage like this service does. – iProgram Jan 27 '16 at 13:28
  • 1
    @iProgram, a "forgot password" link also leads to support problems and if secure access is needed a "reset password link" can not just be emailed to the person. – Ian Ringrose Jan 27 '16 at 14:10
  • 1
    Admittedly, typing certain characters on a mobile device can be very tricky and more trouble than it's worth. I know that a password I used frequently prior to owning a smart-phone turned out to be very non-mobile friendly. Nowadays, I can see people creating a password that includes a half a dozen Emojis or foreign language Unicode mixed in with other characters... Limiting them to standard ASCII does make sense just from an ease-of-use standpoint, let alone technical. – Darrel Hoffman Jan 27 '16 at 17:58
  • 2
    I now mostly use lower case letters, as on a smart phone, it takes as long to type two lower case letter then 1 number or upper case letter. – Ian Ringrose Jan 27 '16 at 18:17
8

Some of the symbols may not be available on all keyboard layouts you interact with. That would prevent you from logging in. This would be a problem for availability, not for security.

But this could become a slight problem of security if the symbol in question were available on an unfamiliar keyboard layout you are working with, but not in a familiar position. In that case, you might have to find out the right key before typing it into the password field. And (particularly in the absence of matching keycaps) you could conceivably type symbols into some editor until the symbol you search for appears. When you stop there, people who get a glance at your editor (while you type or later on because you forgot to close it) will know at least one of the symbols contained in your password.

I have to agree with Eddie Studer's answer: even though there is a far-fetched security implication, chances are that the person telling you about this had no clue as to the real reason behind that policy. It might however have been the availability problem I mentioned up front, of users not being able to log in e.g. from internet cafes in foreign countries. Just to provide one alternative to the injection concerns voiced by most other answers, even though those still are a very likely reason.

Community
  • 1
MvG
  • 745
  • 5
  • 10
  • 1
    I one of companies I worked for, we had user that somehow managed to put tab character in his password. Then we got bug report that he can't enter his password. So, limiting character set doesn't have to be always bad idea. – el.pescado - нет войне Jan 27 '16 at 18:23
  • @el.pescado How do you put tabs in passwords? It just puts you on the next field on the site or browser or doesn't it? Or did they type `\t`? If so then the password wasn't sanitised before. – iProgram Jan 27 '16 at 22:37
  • 5
    If you're copy-pasting the password from, say, a text document and include the tab _there_, it can totally be used in a password field. – Félix Saparelli Jan 28 '16 at 10:29
  • In some contexts, you can press CTRL-I to input a tab character. Notably, however, this doesn't happen in IE (I believe it tries to create a bookmark to the current page, there). – Dan Henderson Jan 31 '16 at 06:28
5

Most people can't type symbols without slowing down and pressing multiple keys at once, so there is a small decrease in security if you're trying to type where you might be observed by a human.

Pete Kirkham
  • 181
  • 5
  • 1
    But when you use a password manager like I do (and I'm sure many others), it slows you down that way. This is because you either have to remove the symbol your self, or you need to change the password type, which makes it less secure because the password is shorter. – iProgram Jan 27 '16 at 13:06
  • 1
    @iProgram most people don't use password managers, and most password managers allow you to change the password or generate passwords without symbols. – Pete Kirkham Jan 27 '16 at 13:09
  • With my password manager, I can filter the symbol out, however it makes the password shorter, therefor less secure. – iProgram Jan 27 '16 at 13:27
  • 1
    @iProgram then it's your password manager which is making the password less secure. – Pete Kirkham Jan 27 '16 at 16:31
  • Only because I can't have a long password with no symbols. – iProgram Jan 27 '16 at 17:58
  • 1
    @iProgram If your password manager doesn't let you store passwords of any characters and of any length, it's a pretty poor password manager, and that limitation has nothing to do with the point I was making. – Pete Kirkham Jan 27 '16 at 20:59
5

Your argument is:
1. a randomly generated password with symbols is stronger than a randomly generated password of the same length with just letters and numbers
2. therefore allowing symbols in passwords make them stronger.

This is valid if and only if people generate passwords randomly.
Let's however compare a password created with the following algorithm:
1. create a password of maximum length - 1 with numbers and letters
2. stick a symbol at the end

Assuming that the number of symbols is less than the number of letters and numbers, this will yield a weaker password than a random password of just letters and numbers, plus provide a false sense of security (`I set it to password$, not password!). Similar arguments can be made for generating passwords by replacing letters with symbols etc.

So one might decide that they'd disallow symbols, in hope that people will choose to use a random/longer password instead of pa$$word. Of course, this "hurts" the users that want to use random passwords with letters + numbers + symbols. But you'd expect that those users will be sufficiently educated to simply add a few more characters, resulting in a password of equivalent strength (assuming you are not limiting the length).

All in all, just because including symbols in some passwords increases their strength, it doesn't follow that allowing people to use symbols will increase the strength of the average password.

Thanos Tintinidis
  • 159
  • 3
2

Alternatively to their own security, imagine that you have to remember password containing upper and lowercase letters, digits and special characters, most of people going for them would write that password on a piece of paper, possibly together with their login, that would be considered high security risk
And if you use simpler password that you can remember there is much lower chance of it leaking from you
Of course this way they block your ability of using complicated password with password manager, solution safer than piece of paper but still I would consider it less secure than simply remembering your password or passphrase
But telling if they had any reasonable reason or just their system or management is flawed is impossible without being insider

zakius
  • 23
  • 4
  • 2
    A common procedure is to think of a pass *phrase*, and *derive* the actual password from it. You *remember* the phrase, but *use* a much more cryptic password. "Yesterday night - I had five eggs for breakfast!" --> "Yn-Ih5efb!" – DevSolar Jan 27 '16 at 09:09
  • This is the thing, I use a password manager. Because of this, I had to use a shorter password that I had to repeat twice to make it secure (It would have took 15hr to crack but repeating it takes 377bill years to crack). I take the extra measures like that just incase an hacker has powerful hardware, or they have "donated" power which is possible for things like this. – iProgram Jan 27 '16 at 10:53
  • 2
    Due to how password lists can be derived, a shorter password repeated isn't that much more secure than the original short password. Use a longer *random* password instead. – Félix Saparelli Jan 28 '16 at 10:33
2

XML / Json Hypothesis:

May be the password is sent to a webservice (hopefully through a safe channel) and they found that special characters resulted in invalid XML or Json. Instead of escaping entities they restricted all symbols.

One security issue is that if you are able to use the escape characters " in XML and \" in Json and the XML/Json is built by String concatenation without CDATA or escaping you may end with a quote in the field even if you checked the String for single and double quotes.

Of course the solution is to avoid string concatenation for building queries with outside parameters.

P.S: The password might also go to LDAP opening the possibility to LDAP injections

borjab
  • 339
  • 1
  • 8
2

I avoid symbols in passwords because they may be difficult to type, especially on keyboard layouts or devices I'm not familiar with.

Also, more importantly, I don't often trust all software developers. Once I used passwords containing spaces. Some services later changed their authentication methods so that they stripped blank spaces from passwords. This made me unable to login.

My fear is that similar things may happen with other symbols too, especially if we consider non-ASCII symbols. By the way, the fact that your customer services are discouraging the use of special symbols is a strong indication of the fact that they shouldn't be trusted and they may do weird things (either now or in the future).

After all, if you think about numbers, using symbols is not much different from adding a few characters to your alphanumeric password:

  • 100 symbols (all ASCII printable characters), length 8: 1008 combinations;
  • 62 symbols (ASCII letters and digits), length 9: 629 combinations, greater than 1008.

Using more symbols helps, but increasing length is much better (kx grows faster than xk).

Andrea Corbellini
  • 121
  • 4
1

But limited characters is pretty common for both password and username.

In secure computing you have something called attack surface, vulnerability, and exploit. Separate is reliability.

Yes more character is more random but you also have a larger attack surface.

You can create sufficiently random passwords with a limited character set. 36^8=2,821,109,907,456 is sufficiently random for most security needs. If not then just raise it to 10 or 12 characters. You can only hope they use random characters. The vulnerability there is passwords you can guess FistNameLastNaveYYMMDD where YYMMDD is date of birth.

Some Unicode character look the same. You can create a diacritic as a separate character. These characters are not the same: Greek Ο, Latin O, and Cyrillic О.

Depending on character set (code page) on your computer you may actually get different mappings. The idea is a safe set of deterministic characters across character sets.

You need to consider HTML encoding, compression over the network, salting, .... What about control characters?

You have to draw the line some where and the fact is you don't need a large character set to create sufficiently random passwords.

This not about programmers being lazy or deficient. It is about delivering solid reliable code. With a controlled character set can better test all possibilities. If something weird happens in transmission there is a smaller test set to figure out what breaks it.

paparazzo
  • 181
  • 7
0

This particular sequence is just holding down SHIFT and typing 1234567890. So I am assuming that they are disallowing this particular sequence because it is simple for a hacker and a lot of people do this. For example, I have seen people use QWERASDFZXCV for a password which is insecure because you are just holding shift and moving down the left side of the keyboard.

Martin Smith
  • 103
  • 4
Denver Coder
  • 1
0

As @dr jimbob said you are using the non printable character £ in your password !@£$%^&*(). If you remove the non printable character £ from your password it will be accepted what ever be the service. This is because the password encryption was developed in c or in Java in core level to maintain the high level of security.

It is difficult make the non tech people to make them understand non printable characters. So the customer care executive asked you to use the simple alphanumeric not the special characters.

Try your new password with !@$%^&*() kindly change the password after testing as it was published online.

Simply speaking the accepted characters are between ASCII 32 to 126

Shameerariff
  • 101
  • 1
  • The same issue happened with all symbols. Even @ – iProgram Jan 31 '16 at 10:03
  • Then in order avoid mysql injection and other related issues as said by @john detters – Shameerariff Jan 31 '16 at 11:42
  • Where do you get the idea that `£` is a non printable character? The fact that we can read it shows it isn't. And "This is because the password encryption was developed in c or in Java in core level to maintain the high level of security" just sounds like nonsense. – Martin Smith Jan 31 '16 at 16:41
  • @MartinSmith Kindly check this http://web.itu.edu.tr/~sgunduz/courses/mikroisl/ascii.html for list of non printable and characters and check this stackoverflow link http://stackoverflow.com/questions/15836744/why-are-non-printable-ascii-characters-actually-printable to know more about it. – Shameerariff Feb 01 '16 at 03:54
  • @Shameerariff - And in your link `£` doesn't appear anywhere in the table of non printable ASCII characters. It appears in the extended ASCII characters. And what relevance does this have anyway? Java strings are natively UTF-16. – Martin Smith Feb 01 '16 at 07:59
  • @MartinSmith Generally the binary values exceeding 7 bits are non printable apart from the regular one like delm null etc, but when comes to £ the hex value is a3 ie 1010 0011 here the 8th bit is 1. So it is not printable for reference you can check the site https://en.wikipedia.org/wiki/ASCII#Variants – Shameerariff Feb 01 '16 at 09:16
  • You Keep Using That Word, I Do Not Think It Means What You Think It Means - Non printable characters are things like white space and control characters that literally do not show up when you print them. – Martin Smith Feb 01 '16 at 09:19
  • I got your point, The non printable character is something which cannot be printed by terminal ie tty. if you try to print the ascii characters of the hex above 127 you will not get it, instead you will find a couple of characters. For your reference I will write a simple code in c and try the same – Shameerariff Feb 01 '16 at 09:23
  • #include #include #include int main (int argc, char *argv[]) { FILE *fr; char ch; fr=fopen(argv[1],"rb"); if(fr!=NULL) { while((ch = fgetc(fr)) != EOF) { printf("\t%c hex value is %d\n",ch,ch); } } fclose(fr); return 0; } and the input file with the following data € ‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ Ž ‘ ’ “ ” • – — ˜ ™ š › œ ž Ÿ ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ­ ® ¯ ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ – Shameerariff Feb 01 '16 at 09:35
0

Often user input is combined with other information to produce a larger block of data, in a structured text format such as a database query, web page or command line. This larger block of data is then later interpreted.

This leads to a class of attacks known as injection attacks. The user crafts their input such that when the larger block of data is assembled and re-intepreted the user input is interpreted not as field content but as part of the structure.

In general there are three main ways to defend agains such attacks.

  1. Filtering. Limit the user to a subset of characters that you can demonstrate are safe. Ascii alphanumerics are nearly always safe. The nice thing about filtering is you can apply the same filter multiple times without breaking anything, that is hugely valuable if trying to retrofit an existing system.
  2. Escaping. Replace the threat characters with some special sequence. The problem with escaping is that escaping needs to match up precisely 1 to 1.
  3. Parameterising. Store the untrusted data in a seperate data structure and . This can be the best soloution, but it's not always pracitical.

Non-ascii characters can open up further cans of worms. Some characters are visually indistinguishable, some characters are invisible, some characters break up the normal ordering of character display. Some formats may have multiple representations of the same character or the byte sequence for one character may be a subsequence of the byte sequence for another character. This can create opertunities to "smuggle" characters past filtering or escaping processes.

If you have a legacy system that you know is full of holes, then restricting all untrusted input to ascii alphanumerics may be a sensible defense measure.

That said, putting such restrictions on a password field rings alarm bells, in general systems should do as little processing as possible on passwords in their plain-text form and should convert them to password hashes ASAP. So there is little chance of the attacks mentioned above on password fields.

Peter Green
  • 4,968
  • 1
  • 22
  • 26
  • I'm not sure what you intended to add to all the other answers from 6 years ago. You appear to repeat many other answers. – schroeder Aug 26 '22 at 19:44