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

  • 5
    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
    Commented Jul 13, 2012 at 20:36
  • 10
    By special characters are you referring to ASCII special characters like ,./<>?;':"[]{}\|!@#$%^&*(-=_+ or unicode characters , £, as p____h's answer suggested?
    – dr jimbob
    Commented Jul 14, 2012 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. Commented Mar 20, 2013 at 23:05
  • 1
    Sometimes, no technical reason. See this great (and hilarious) response to a similar question about password length: security.stackexchange.com/questions/33470/…
    – Omer Iqbal
    Commented Jun 18, 2014 at 3:20
  • 1
    Here's another very similar question on a sister site
    – Gary
    Commented Jul 3, 2015 at 19:55

10 Answers 10


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

  • 11
    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
    Commented Apr 29, 2013 at 10:38
  • 9
    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
    Commented Jan 28, 2015 at 15:14
  • That's probably a good part of the explanation... it's ironic and sad.
    – Francesco
    Commented Dec 29, 2015 at 14:35

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.

  • 8
    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
    Commented Jul 14, 2012 at 9:54
  • 10
    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.
    – user4516
    Commented Jul 16, 2012 at 14:27
  • 41
    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
    Commented Mar 16, 2013 at 8:30
  • 7
    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
    Commented Sep 11, 2013 at 7:14
  • 2
    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
    Commented Jan 26, 2015 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.

  • Ya, or just convert the password to hex or base64 encoding before storing it in the DB... The password is the single most important security feature. Probably ought to be worth doing it right. Honestly, the only part of the password the DB should see anyways is a hash which is always pure binary.
    – ebyrob
    Commented Nov 1, 2018 at 21:01

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.

  • 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
    Commented Jul 13, 2012 at 22:07
  • 1
    p___h - your comment makes no sense. Part of a security audit will look for things like bound parameters etc
    – Rory Alsop
    Commented Jul 13, 2012 at 23:08
  • 1
    @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
    Commented Jul 14, 2012 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
    Commented Jul 14, 2012 at 1:45
  • 1
    @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
    Commented Jul 16, 2012 at 4:55

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

  • I wouldn't consider hashing a password a solution to SQL injection. If you have code that would be vulnerable without hashing the input, you're in trouble. Not all inputs are passwords. The problem is immediately resolved by using bind variables with prepared statements.
    – Brandon
    Commented Apr 22, 2015 at 23:11
  • 1
    He's specifically referring to passwords in this case, though... so... hashing is absolutely a solution to SQL injection on the password field ALONG WITH prepared statements.
    – KyleFarris
    Commented May 6, 2015 at 20:11
  • SQL injection can be thwarted with prepared statements regardless of how the passwords are stored. Without prepared statements you're risking introducing SQL injection vulnerabilities regardless of how the passwords are stored. Passwords are not the problem with SQL injection. Commented Feb 14, 2017 at 5:03

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.


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.

  • 5
    (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
    Commented Jul 13, 2012 at 20:47
  • 4
    Why would you need to validate the password at all if you just hash it before working with it?
    – Gary
    Commented Jul 13, 2012 at 20:48
  • 2
    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
    Commented Jul 14, 2012 at 1:24
  • 1
    @Iszi - definitely, but this is easy
    – Rory Alsop
    Commented Jul 14, 2012 at 9:20
  • 3
    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
    Commented Jul 14, 2012 at 12:24

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!

  • Your last hilighted paragraph is good, but must of the preceding text seems largely irrelevant.
    – supercat
    Commented Oct 14, 2016 at 23:29

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.


  • 3
    Since it's actually easier to increase security by increasing the length of the password, somebody is fooling themself. The kind of people likely to use special characters are probably less likely to forget them, too... Commented Mar 17, 2015 at 13:51
  • 1
    Isn't this covered by p____h's answer?
    – schroeder
    Commented Mar 17, 2015 at 15:09

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.

  • 3
    So you're saying the user should not be allowed to use any characters other than a and m because he might be using a dvorak keyboard layout by accident.
    – SOFe
    Commented Jan 20, 2020 at 4:51
  • 1
    @SOFe: Someone who had the wrong alphabetic set selected would likely notice fairly quickly during normal use. Someone who used a keyboard layout that was fairly "normal" except that some special characters were in weird spots wouldn't notice unless they typed those special characters into a field that would make them observable.
    – supercat
    Commented Apr 24, 2023 at 16:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .