Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question
I suppose they could be encrypting the passwords, but I've always been told this is a terrible idea as well. –  Gary Jul 13 '12 at 20:12
even encryption means nothing character wise, modern encryption operates on the binary level. However I'll let you consider banks and the like that ask for x, y and z characters from password... –  ewanm89 Jul 13 '12 at 20:36
By special characters are you referring to ASCII special characters like ,./<>?;':"[]{}\|!@#$%^&*(-=_+ or unicode characters , £, as p____h's answer suggested? –  dr jimbob Jul 14 '12 at 4:01
Ally Bank does not recommend special characters in your password if you going to access your account via android. Completely stupid. At least standard characters like a ? should be allowed. –  Gabriel Fair Mar 20 '13 at 23:05
Sometimes, no technical reason. See this great (and hilarious) response to a similar question about password length: security.stackexchange.com/questions/33470/… –  Omer Iqbal Jun 18 '14 at 3:20

8 Answers 8

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.

share|improve this answer
(Because I'm sure this will come up...) Isn't there a better way to protect against such scripts/exploits, while still allowing special characters in passwords? –  Iszi Jul 13 '12 at 20:47
Why would you need to validate the password at all if you just hash it before working with it? –  Gary Jul 13 '12 at 20:48
And it allows a targeted attack to limit it's scope and decreases the entropy of possible passwords. Surely the input validation on passwords should be the full character set and it should pass straight into a hashing algorithm? –  ewanm89 Jul 14 '12 at 1:24
@Iszi - definitely, but this is easy –  Rory Alsop Jul 14 '12 at 9:20
What Rory said. Yes, if you handle your characters correctly by always using the right kind of escaping, you are safe. But that requires coders who know what they're doing, and they are in short supply in the financial industry. Much easier to take the quick, crap fix. –  bobince Jul 14 '12 at 12:24

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.

share|improve this answer
Almost every financial institution which stores data related to your personal information and your cash had got strict security audit, which should be repeated after any significant change in the system. So it's hard to believe in information from your second paragraph. –  p____h Jul 13 '12 at 22:07
p___h - your comment makes no sense. Part of a security audit will look for things like bound parameters etc –  Rory Alsop Jul 13 '12 at 23:08
@p____h Financial institutions tend to be the ones to make up there own rules and regulations to audit against, and it's not always best practices. It also tends to be up to them when they repeat any audits. –  ewanm89 Jul 14 '12 at 1:31
Shouldn't be there any regulations when this institutions want to collect any personal data? AFAIK, not everyone could process personal data, you need to have permission for that and follow regulations, when you want to process them (or maybe it depends on country). –  p____h Jul 14 '12 at 1:45
@drjimbob "Silently stripping characters out of other fields (like comments)," why? Can't you just indicate "your comment includes of these characters (...) which are not allowed"? –  curiousguy Jul 16 '12 at 4:55

What about the support cost? Let's say that we allowed anyone to create password consists of 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 the mobile-phone? It's easier to type from our keyboard than from the mobile phone.

What about holidays? We are in the UK, which only access to the UK-keyboard. Instead of we can easily type £. The word easily is very important here. For some average users, typping that chars for the "new" keyboard could be a problem. How will he be trying to solve it? He will probably call bank-support to ask them to change his password or ask why the € character dissapeared from his keyboard.

share|improve this answer
This is a problem anyway, how easy is it to type your English password on a Chinese or Arabic keyboard, as for my phone, all those characters you asked for are immediately accessible in uk layout mode. Switching the layout on the OS and pressing the same pair of keys works whatever the markings on the key caps are. –  ewanm89 Jul 14 '12 at 9:54
I know it's just conjecture, but the type of user who can't figure out how to re-type their password and believes the key "disappeared" from the keyboard is probably not making clever passwords with special characters, but using ones like goldfish2. –  Wesley Murch Jul 16 '12 at 14:27
Absolute bullshit. If you create a password with the arbitrary characters then it's only you who should care about how to retype such a password. It was your own decision after all! Any type of input should be allowed as a password, with any sane length, especially with such an important things like the bank account. We're hashing this passwords/passphrases anyway, there's absolutely no point in restricting the charset. It's a total madness. –  hijarian Mar 16 '13 at 8:30
A restriction (whether it is forbidding the use of special chars or making them mandatory) does not make things easier for the user. If nothing else, it will make some users unable to use their “usual” password and force them to create/remember another one (which you might find desirable for other reasons but it is still objectively annoying and as such not “easy”). –  Relaxed Sep 11 '13 at 7:14
This is the sole reason I haven't tried to change my passwords to 私は何か and other non-ASCII variations. I can't guarantee I'll be able to enter it wherever I need to –  Izkata Jan 26 at 21:26

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
This is a major problem with security. +1 for pointing out one of the biggest flaws in IT security at least in my opinion. –  Nomad101 Apr 29 '13 at 10:38
Of course, this means that the passwords are not stored in a hashed format. If they were hashed then even older systems would not be an issue. –  NotMe Jan 28 at 15:14

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

share|improve this answer
I agree with most of what you're saying but you how are you going to hash the password from the client if JavaScript is disabled? –  Gary Apr 16 '13 at 0:20

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!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.