American Express also limits password for their online banking functions to less than 8 purely alphanumeric characters (no spaces, no special characters). If this alone wasn't bad enough, this almost certainly means that somewhere deep in the bowels of AmEx's software stack there's an ancient system where the password field is in plain-text.
AMEX isn't the only one with arcane password restrictions. Most banks limit the characters to an alphanumeric subset of ASCII with a few characters like _, and -. It makes no sense.
If that wasn't bad enough, look at how services like Mint have to interface with these institutions? When will something like OAuth come into play at banks?
I'd love to charter a bank on the premise of superior online service.
I wonder about this, same for my bank. My theory is alphanumeric plus one, maybe two symbols means there is a lower probability of some sort of SQL injection. Perhaps a greater risk for exposing one account, but lower risk for exposing many.
There are ways around legacy systems not storing certain characters to database field sizes that range from running delegate password serves to hashing passwords into something that an be stored on the legacy system. The one thing this thread does get at is the money involved. To Amex the costs and risks of their "weak" password requirements don't outweigh those of implementing a more secure password system.
I'd dare say that if a financial institution ever had a situation where an attacker could see any part of their database, they'd have far bigger problems to deal with.
I can't speak for most financial systems (I only am familiar with one, but it's a big one), but I know plain text passwords happen. Lets call the system IET.
IET doesn't encrypt the passwords used for internet banking. To obscure the passwords, they're stored in the DB using EBCDIC. No joke.
Sure, in theory, encryption of data at rest doesn't matter if the system is secure; however, with a security posture like this, the data is bound to leak.
In this case, I found out about the unencrypted passwords because they were in the files going to the "print & statement" vendor: there is a default letter in the system that says "Hey your password changed to foo99!". Despite suppressing this letter, the data was still transmitted to the vendor: it is simply ignored.
I feel like this gets brought up every week here, but I'll post it again: If your password is going to be the same for the phone as it is for the internet, it can't have special characters.
