Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.
It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here to provide a subject for you to point your finger at should there be a breach".
Many banks are encumbered by old mainframe systems that still do a lot of their computing. I don't know how much of that bubbles up through to the web interfaces we deal with, but I know many tellers and agents are still on green screens, or on interfaces that are just pretty wrappers to mainframe terminals.
I've heard that excuse from banks and such before, and, frankly, I suspect they are lying.
Oh, I fully believe that whatever ancient mainframe they are using might limit passwords to some small number of mono case characters with no funny characters allowed.
However, that would only apply to passwords for mainframe accounts. The bank is NOT going to be creating a login account on the mainframe for each bank customer. Our bank accounts are just entries in an application database on the mainframe.
If there is some kind of per customer password that the mainframe stores with the bank account data and that the online system has to provide when sending transactions to the mainframe, and it has such a limit, and the bank cannot update the application and database for some reason, that still should not be visible to the customer doing online banking.
The part the customer sees online should have its own password database, which allows good passwords, and in there it should have (encrypted!) whatever the ancient limited mainframe password is for that customer's account.
Unless the web interface itself runs on an ancient mainframe, I strongly suspect that there is no acceptable excuse for only allowing short passwords from a limited character set.
Banks are simply not very good at security, or they don't care. Hell, they insist on mailing me things that include my full credit card number, ensuring that someone who wanted to inconvenience me just has to drive by my mailbox at the right time and steal my statement. How freaking hard would it be for them to X out all but the last 4 digits. Yes, that would mean someone whose statement covers multiple cards might have a collision--so don't issue two cards with the same last 4 to two people who receive a joint statement.
The reason they don't allow special characters is to prevent situations where the customer has forgotten his password and needs to go through an excruciating verification process to access his own account.
As someone that penetration tests a lot of banks it does sometimes make it's way through. Larger and more established banks (at least in EMEA) sometimes tend to use highly distributed systems that all interoperate in very strange ways, which can sometimes lead to interesting results on web application penetration tests (e.g. there's no data store, so no SQL injection but there'll be some obscure pre-relational data store you can inject right into if you only know how to talk to it).
It's not that easy to get rid of either, the banks have to support internal applications that expect things in those formats, as well as all the unofficial apps that plug in via messaging systems and may not be aware of the other app from either end.
At last Chase allows us to have rather long passphrases (mine is well over 16 characters). Discover has the same alphanumeric-only rule, but limits you to 10 characters. 10. Then we have the silly little sites that don't retain any important information aside from a contact email that force you to have high entropy and two-byte non-latin characters in your password. (OK, so that's an exageration, but not much of one.)
Funnily enough I opened a new bank account the other day (Chase) and to my surprise they don't allow special characters to be used in the passwords.
Special characters don't make as much of a difference as password length: http://xkcd.com/936/ (a comic that must appear on any password-related thread). According to the XKCD analysis, an 8 character password based mostly on letters with some numbers and symbols has ~28 bits of entropy, while a random four word password has 44 bits. [Edit to add: http://news.ycombinator.com/item?id=4083381 claims over 3 billion MD5 hashes a second for $1000, meaning your 28-bit password could be cracked effectively instantaneously by a high school kid buying phishing gear with stolen credit cards or a summer job].
If you're an international web site, it might make sense to disallow symbols, as your customers may not be able to enter their chosen symbols when traveling internationally.
The short XKCD password is based on a dictionary word, making it vulnerable to intelligent brute force (oxymoron of the day).
I imagine the calculation goes something like this:
1/50000 Likelihood of a particular uncommon word
1/8 Substitute up to three letters for numbers
1/2 Initial capital or initial lowercase
1/32 Add a punctuation character at the end
1/10 Add a digit at the end
1/2 Possibly swap punctuation and digit at the end
----------------------------------------------------------
1/512000000 Resulting probability
-28.93157 log2(1/512000000) -- number of bits of entropy
So, if e.g. XKCD assumed only 25000 uncommon words to choose from, that would give ~28 bits of entropy.
Thanks for the thorough answer! I originally missed the part about using a real word as the base.
For my passwords, I use 8 character random strings so hopefully I am a little safer. Although, as I'm learning from all of these password leak debacles, you are only as secure as the systems using those passwords.
I also have Chase and have heard the explanation for not allowing symbols in passwords to be that they are harder to grep out of logs if someone is keylogging you. Seems like BS to me, but either way is is extraordinarily frustrating to not be able to use a strong password for your bank.
Something even more ridiculous Chase does is assign a default pin of '3210' to checking accounts.
My (German) bank only allows passwords up to 5 characters.
When I ranted about it on twitter some IT guy from a local branch commented about that is totally enough since they do an hour lockout after 3 wrong tries.
o Your German bank may have your password stored in an Utimaco/Sophos Hardware-attack-resistant keysafe, not hanging out in some linux hash file.
o If they lock you out after 3 tries, and the keyspace is [a-zA-Z0-9] - that's 916,132,832 combination, and only three attempts to get it right before being locked out.
On the surface, it sounds much less secure, but, depending on their procedures and hardware, it might be significantly more secure than a 9 character password that goes into a hash file that is software accessible.
Of course - better case - is a Hardware key safe that lets me store my 30 character 1password random password.
I receive spam (not marketing crap, but pump-and-dump penny stock fraud spam) at an email address I created only for use at TD. Either they sold their email database to spammers, or they got hacked and failed to disclose it.
It indeed appears that the entire system is broken beyond repair. It seems like it is becoming the norm to expect to be exploited at some point so the de-facto preemption is to have someone to blame. As the manager of a datacenter we recently moved into said "we're here to provide a subject for you to point your finger at should there be a breach".
WTF, industry.