Registering on an insurance company's website right now, and my password is 16 characters long, using a nice variety of letters, numbers, special characters, etc. However, here's their list of restrictions:

Note your password:

  • must be between 6 and 12 characters
  • must not contain spaces, special/international characters
  • must not contain your user name, first name or last name
  • is case-sensitive
  • should contain at least 1 number and 1 letter

I can understand minimum 6 characters, not allowing parts of your name, being case-sensitive, and needing at least 1 number and letter. The part I don't get is restricting your choice of characters you can use, and having an upper bound.

Why do websites do this? The only thing I can think of it they don't know the basics of hashing a password, which would secure it better than anything, and get rid of any security concerns.

If I choose to type DELETE FROM users WHERE 1=1 as my password, I should be allowed to. PHP's MD5 hash of it becomes fe5d54132b51b7d65ab89b739b600b4b which I don't think will harm anything.

  • 7
    One of the banks I use enforces a max of 6 characters and disallows anything that isn't alphanumeric. I feel your pain and confusion. :(
    – Adam Lear
    Commented Oct 28, 2010 at 14:29
  • 8
    I can't answer the question, only add that I HATE this. It seems like financial institutions where I feel most paranoid about my accounts are always the places that limit my passwords to 10 alphanumeric characters. Then I'm always forgetting them because I have to dumb them down. I just don't get it. I'm not asking for full Unicode support as mentioned below, just plenty of ASCII. Commented Oct 28, 2010 at 14:43
  • At least one of the top 5 banks in Canada only allows 8 characters max also
    – Viper_Sb
    Commented Oct 28, 2010 at 15:10
  • 4
    My credit card provider insisted I create some "memorable information" for logging in with. This memorable information had to be between 8 and 16 characters, contain both letters and numbers but no non-alphanumeric characters. Who on earth has any memorable information that matches that pattern? I hate it.
    – glenatron
    Commented Oct 28, 2010 at 15:25

6 Answers 6


It comes down to their programmers (or their management) being lazy and/or uneducated. It doesn't take that much more work to make your system accept any characters, but it means you need to spend some time thinking about SQL injection attacks, cross site scripting, making sure that all parts of the system are able to deal with it, etc. It can be cheaper and quicker just to forbid any characters that could be a problem.

  • User-supplied passwords should never be put into any databases, or used in any other way. They should be hashed with a strong salted hash and the hash stored in the database. There's no possibility of SQL injection, etc. Commented Jul 15, 2021 at 18:36

Usually the restrictions on "extended characters" are because the management in bank programming groups used to be COBOL programmers, and know that Character Sets Are Hard.

  • That's as good an explanation as any. Commented Oct 28, 2010 at 20:23
  • 1
    Or even better, that the password validation routine actually is written in COBOL, with a PIC X(12) field. On a system that uses EBCDIC.
    – dan04
    Commented Feb 20, 2011 at 16:47

Banks restrict the special characters, probably because they are storing the passwords in plain text, which they shouldn't be doing, and they are afraid some special characters will leak into their business logic and hack it.

As to the limit of number of characters, I can only speculate that software on some of the mainframes they still use cannot handle text fields larger than that.

  • 4
    "banks are storing passwords in plaintext" Link for proof of this?
    – Chris
    Commented Oct 28, 2010 at 15:09
  • @Chris: You're right; I can't prove that. My credit union is like Fort Knox; I don't access my account that often, their requirements for passwords are downright draconian, and I can never remember what my uncle's wife's dog's maiden name is. I have redacted that part of my answer; the real threat is securing the password reset mechanism with publicly available information, see here: scientificamerican.com/article.cfm?id=anatomy-of-a-social-hack Commented Oct 28, 2010 at 16:21
  • 1
    @Chris: I have no evidence, but I'd be worried that they might be that ignorant of security. Commented Oct 28, 2010 at 16:47
  • a good read. Reminds me why I like sites (the few and far between) that let you enter your own question. Mine becomes a single word with a question mark that nobody could ever guess the answer to.
    – Tarka
    Commented Oct 28, 2010 at 18:57

I can understand prohibiting special characters, but there is no excuse for password length limits. I use a password manager and like to use ridiculously long passwords. Since I don't have to remember them or type them, why not?

I can think of only one reason why a site might limit password length. The people who run the site are afraid that if they let their users use really good passwords, they will forget them more frequently and they will have to field a couple more support calls or emails. It's a very lame excuse, but it's the only possible reason for such a stupid policy that I can come up with.

  • 1
    It's not exactly unusual to have a database design where the devs decide the field can be up to X characters in length. Some things should be unlimited text lengths, sure, but it's normal enough to limit others. Commented Oct 28, 2010 at 16:23
  • 12
    @Kate: That only applies if the devs decide to keep the password as is, rather than to store it in one-way encrypted or hash form only. That is a major security problem, and I'd rather not do business with people who don't understand that. If they do things right, they've got a fixed-length hash and no problem with allocating the right space for a key. Commented Oct 28, 2010 at 16:46

This decision seems to be based around what is practical for most users. Unlike programmers and techies, many users of online banking seem to have difficulty remembering a 4 character pin, let alone a password of decent length. Which is one of the drivers for 2-factor authentication - give them a device which produces a password so all they need to do is not lose the device!

With respect to the "why no special characters" - it isn't laziness, it's a sensible decision on reducing the potential attack landscape. If you allow apostrophes, hashes, equals signs etc, you need to be 100% confident your input validation routine will catch SQL injection attempts for example - if you whitelist only those chars you want to appear in the input, you save yourself a whole lot of potential damage.

I agree in principle with Matteo - in an ideal world passwords should only be stored with a 1 way hash, however a bank would lose customers if they did this, so there has to be a way. Often, in addition to the hashes stored in the main database, there is an encrypted field, either in the same database, or in a separate passwords database just for this function


Not that I agree with the password restriction in this case, but generally allowing full set of unicode characters for password might introduce some problems. E.g. if the system allows retrieving password via email through some validation mechanism, the password might not get rendered properly in the email client due to lack of unicode support.

As for why spaces and other special characters are no allowed, e.g. in the password retrieval email:

Your password is :actually something else, not this one

Ermm... confusing yea?


Your password is ActuallySomethingElseNotThis1

  • 39
    passwords should not be able to be retrieved by email, I hate that. It means my password is stored in plain text somewhere. it should be reset only.
    – WalterJ89
    Commented Oct 28, 2010 at 14:37
  • 1
    @WalterJ89: Wish I could upvote your comment more than once.
    – webbiedave
    Commented Oct 28, 2010 at 14:50
  • 12
    Password retrieval is the most retarded thing I can think of about security. Password MUST ALWAYS be stored with a one-way encryption algorithm with NO WAY to be decripted back to their original text form. The only option must be password reset by identifing the user via other security means, like security Q&A or other personal information only the legitimate user should know about. Commented Oct 28, 2010 at 15:10
  • @Walter - Completely agree. Sadly, I've had plenty of clients say "that's too any steps, our customers won't like it" I usually say "well they like it when you get hacked and their information is stolen?" They still go with "fewer steps" Commented Oct 28, 2010 at 21:03
  • 1
    @Jack. There arn't really that many more steps involved. at worst it can be "Here is your new password" with the same number of steps.
    – WalterJ89
    Commented Oct 28, 2010 at 22:48

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