# Why did customer services say using symbols in a password is insecure?

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.

• 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. Commented Jan 26, 2016 at 19:03
• Nitpicking your math: typically passwords are case sensitive, so only allowing letters and numbers would have 62^8 combinations instead of 36^8.
– TTT
Commented Jan 26, 2016 at 19:59
• 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. Commented Jan 26, 2016 at 20:50
• Because they're wrong. Commented Jan 27, 2016 at 1:59
• Because one of the them is called Little Bobby Tables and they have learnt their lesson: xkcd.com/327 Commented Jan 27, 2016 at 10:11

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?

• 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? Commented Jan 26, 2016 at 19:21
• 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. Commented Jan 26, 2016 at 20:28
• Mmmm...password hash. Breakfast of champions. :-) Commented Jan 26, 2016 at 20:42
• 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. Commented Jan 26, 2016 at 22:29
• Comments are not for extended discussion; this conversation has been moved to chat. Commented Jan 27, 2016 at 17:41

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.

• This seems reasonable and is what I was thinking. Commented Jan 26, 2016 at 19:24
• 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. Commented Jan 26, 2016 at 19: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.

• 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... Commented Jan 26, 2016 at 19:43
• 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. Commented Jan 26, 2016 at 20:46
• 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. Commented Jan 27, 2016 at 16:22
• 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. Commented Jan 27, 2016 at 20:38
• @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. Commented Jan 29, 2016 at 5:45

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 Å 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. • 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. Commented Jan 26, 2016 at 21:39 • 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. Commented Jan 26, 2016 at 22:27 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. • Hence why you have a "forgot password" link on your webpage like this service does. Commented Jan 27, 2016 at 13:28 • @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. Commented Jan 27, 2016 at 14:10 • 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. Commented Jan 27, 2016 at 17:58 • 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. Commented Jan 27, 2016 at 18:17 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. • 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. Commented Jan 27, 2016 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. Commented Jan 27, 2016 at 22:37 • 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. Commented Jan 28, 2016 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). Commented Jan 31, 2016 at 6:28 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. • 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. Commented Jan 27, 2016 at 13:06 • @iProgram most people don't use password managers, and most password managers allow you to change the password or generate passwords without symbols. Commented Jan 27, 2016 at 13:09 • With my password manager, I can filter the symbol out, however it makes the password shorter, therefor less secure. Commented Jan 27, 2016 at 13:27 • @iProgram then it's your password manager which is making the password less secure. Commented Jan 27, 2016 at 16:31 • @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. Commented Jan 27, 2016 at 20:59 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 paword. 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.

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

• 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!" Commented Jan 27, 2016 at 9: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. Commented Jan 27, 2016 at 10:53
• 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. Commented Jan 28, 2016 at 10:33

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

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).

• 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).

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.

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

• The same issue happened with all symbols. Even @ Commented Jan 31, 2016 at 10:03
• Then in order avoid mysql injection and other related issues as said by @john detters Commented Jan 31, 2016 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. Commented Jan 31, 2016 at 16:41
• @MartinSmith Kindly check this web.itu.edu.tr/~sgunduz/courses/mikroisl/ascii.html for list of non printable and characters and check this stackoverflow link stackoverflow.com/questions/15836744/… to know more about it. Commented Feb 1, 2016 at 3: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. Commented Feb 1, 2016 at 7:59

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.

• I don't think the OP mentioned the sequence of symbols being banned. Commented Jan 28, 2016 at 23:50

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.

• 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. Commented Aug 26, 2022 at 19:44