Why Disallow Special Characters In a Password?

Question

The culprit in this case is a particular (and particularly large) bank that does not allow special characters (of any sort) in their passwords: Just [a-Z 1-9]. Is their any valid reason for doing this? It seems counter productive to stunt password strength like this, especially for a system protecting such valuable information.

The only thing I have been able to come up with is a weak attempt to thwart SQL injections, but that would assume the passwords are not being hashed (which I sure hope isn't true).

Answer 1

One explanation I haven't seen here is that many financial institutions are tightly integrated with older systems and are bound to the limitations of those systems.

The irony of this is that I have seen systems that were built to be compatible to older systems but now the older systems are gone and the policy still must exist for compatibility with the newer system that was built to be compatible with the older system.

(the lesson here is that if you have to be compatible with an old system, allow for some future elimination of those limitations).

Answer 2

What about the support cost? Let's say that we allowed anyone to create passwords containing € chars. Hurray, we are able to use special characters in our passwords. But wait - how on earth we can type that password if we want to get the access to our bank from a mobile-phone? It's easier to type € from our keyboard than from a mobile phone.

What about holidays? We are in the UK, which only has access to the UK-keyboard. Instead of € we can easily type £. The word "easily" is very important here. For some average users, typing that character on the "new" keyboard could be a problem. How will they try to solve it? They will probably call bank-support to ask them to change the password or ask why the € character disappeared from the keyboard.

Answer 3

This can be (weakly) justified as a defense-in-depth measure - if there is an injection or other data interpretation bug, limiting the password character set and length may be able to prevent it from being exploitable. It also somewhat simplifies implementation, since if they only deal with 7-bit ASCII characters, Unicode and multibyte character string handling is irrelevant, and simpler implementations are as a rule less likely to contain bugs.

However, assessing this decreased risk against the increased risk due to lower password quality is not simple - I would expect that as the number of users of a system increases, the number of passwords that could be compromised also increases, making an investment in lifting such restrictions more worthwhile. All that said, most users' passwords will be terrible even if the field is completely unrestricted.

Answer 4

My guess is the policy exists for all user-inputed fields and the same user input policy (no special characters) was applied to fields including passwords for simplicity. Or at some point some bank wasn't hashing passwords and had an SQLi attack through their password field, and a policy was decided that passwords can't have special characters (and the reason for the policy was forgotten once hashing was introduced).

There definitely is a security benefit of not allowing special characters in other user-inputted fields that are not hashed and could be used for various attacks like SQLi or XSS (on a bank administrator looking at an account). However, these threats are generally solved by always using bound parameters in SQL and always sanitizing user-input before displaying/saving to db.

My other guess is that they want to have custom rules that may be different from other places, so you can't easily reuse your standard strong password (which may get lost), and have to come up with something unique for their site.

---

EDIT: On further thought, depending on the language I can think of at least three special ASCII characters that should universally be forbidden/stripped as allowing them only tempts fate. Specifically: \0 (null - ascii 0), since it is customarily used to indicate end of string in C-style languages (possibly users to alter the memory after the end of the string). Also carriage returns and line feeds \r (ascii 13) and \n (ascii 10), as these are often system dependent whether line breaks are \r\n or \n and that brings up the inevitable I can only login on from windows not my mac/linux machine. In fact, it seems quite reasonable to only allow printable ascii (32-126) and ban the non-printable ASCII 0-31 and 127.

But if by special characters you mean unicode not ASCII characters (like ,./<>?;':"[]{}\|!@#$%^&*(-=_+ it seems reasonable for simplicity of implementation from multiple operating systems/keyboards/browsers to not allow special characters. Imagine your password had a lowercase pi in it. Was that the Greek pi (π) which is codepoint 0x3c0 or the Coptic lowercase pi (ⲡ) which is codepoint 0x2ca1 -- only one will work and this type of problem of similar characters with different codepoints will exist in unicode. Your hash which operates on bits will not be able to equate the two π, so if you try logging in different places you may input different characters.

Similarly, though this problem is one the programmer can largely control and attempt to do correct, allowing unicode characters creates encoding issues. That is for your basic ascii characters everything is represented in a one byte number. However, there are a bunch of different schemes for how to encode unicode. Is it UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), Latin-N encoding, and (for some encodings) what's the byte order (little or big endian)? The unicode codepoint for pi (0x3c0) would be represented as bytes 2b 41 38 41 2d in UTF-7, CF 80 in UTF-8, FF FE c0 03 in UTF-16, and FF FE 00 00 c0 03 00 00 in UTF-32. You wouldn't be able to represent pi in Latin-1 (it only has 95 extra printable characters), but if you had an A1 in your password and were in different encodings you may have to represent it from any of the following characters ¡ĄĦЁ‘ก”Ḃ (which in some Latin-N may to A1).

Yes, the webpage may have a charset defined, but users can override the charset on a page in their browser or have copied and pasted data from elsewhere in a different encoding. At the end of the day, it may be simpler to just forbid those characters.

Answer 5

As a generalization, here are the most common reasons that financial institutions restrict length and character set complexity.

(1) The web services are front-end systems to legacy mainframe applications, which often have an eight character limitation made up of only small case alpha and numbers. No "special characters." Oddly this is the most common limitation. +1 to Mark Burnett above.

(2) They are not hashing the passwords, so they can't simply store a fixed length numeric string (i.e. the hash output - 32 bytes of SHA256(password)). As such they have to worry about limiting the size of the input.

(3) The SQL injection threat vector is only a password issue if the passwords are stored as clear text. Many organizations and others are wasting time worrying about escaping the characters of the password, when the problem is immediately resolved by storing a hashed password (ideally salted and stretched using something like PBKDF2).

Other than favoring simple customer support password resets OVER security, there is NO acceptable reason that I am aware of for transmitting a user password in clear text off of the user's device. You don't want the liability, so never accept them. That's what crypto hashes are for.

Here is a great blog post that summarizes some of the best practices and includes code samples. http://crackstation.net/hashing-security.htm

Answer 6

I actually asked a big webshop that (bol.com, not sure if they are international).

Their advice is to use a strong password, change it frequently, use letters and numbers, that it should be long, and maybe some other things I forgot. Anyway, the usual advice that nobody follows. But they seem to care about the password policy.

Yet they don't allow most special characters, and the maximum password length is 12 characters. Upon asking, they told me that otherwise too many people would contact support.

When I mailed them back to ask what the "Forgot your password?" feature was for, I got no reply...

So for banks, where a simple password reset by e-mail is out of the question, I guess support costs are really the reason (like suggested by others here). For any other website like this bol.com, I would highly distrust whether they hash their passwords. You should use a more unique password there, if the database leaks your password is going to be known.

Answer 7

Limiting the character set to alphanumerics limits the likelihood of a script or exploit getting past the input validation stage.

The user can always improve their security by using longer passwords, but the application needs to have a specific whitelist to help prevent attacks.

Answer 8

I can try to give my view of the problem above as a UI interface designer and not a programmer: the key point here is that the login requirement is partly a UI interface design problem and not a programming only problem.

There's an excellent book "Apress - User Interface Design for Programmers" which shows an analogous problem related to window sizes which I'll post below:

Here's a common programmer thought pattern: there are only three numbers: 0, 1, and n. If n is allowed, all n's are equally likely. This thought pattern comes from the old coding convention (probably smart) that you shouldn't have any numeric constants in your code except for 0 and 1.

Now the thinking above is correct in a programming only problem, but as it concerns user interfaces and especially windows it isn't

But it's not true. As it turns out, it's not equally likely. There are many good reasons why you might want a window exactly at the top of the screen (it maximizes screen real estate), but there really aren't any reasons to leave two pixels between the top of the screen and the top of the window. So, in reality, 0 is much more likely than 2.

Now coming to our problem, theoretically all characters should be equally likely and equally permitted from a programming and formal point of view, however here we are also in a UI interface problem instance and we must be aware of it and give the correct weight to it.

So I'll paraphrase an answer from the thread above which in my opinion is correct:

Let's say that we allowed anyone to create passwords which contain the € char. Hurray, we are able to use special characters in our passwords. But wait - how on earth can we type that password if we want to get access to our bank from the mobile-phone? It's easier to type € from our keyboard than from the mobile phone.

That's the main point from a usability point of view and we shouldn't blame it on the user if he realizes some years later with a smartphone when years before they didn't even exist, that he used a character he should have avoid.

It's our obligation to think about this type of problems and let the user avoid it!

Answer 9

A little late to the party - I recently read that the reason for this is that for many banks, the value of the increased security of allowing those characters is outweighed by the implementation cost and the support cost of dealing with customers that cannot remember their passwords.

I'm not saying that its a good reason, but that is how I interpreted what I read.

http://www.theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-twitter-or-google/article18325257/

Answer 10

One more reason! Some special characters change their location based on the keyboard used. For example, the at mark (@) and the asterisk (*) are on different keys in a mixed US-EN and Japanese language keyboard environment. If I had a dime for every time a user got locked out because they were on the wrong type of keyboard scheme... well, I'd have about a dollar or so, but you get the point.