Hacker News Reader

Comment by bradgessler | Hacker News Reader

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.

View on HN

You might be interested in this previous Hacker News post: http://hackerne.ws/item?id=1355292 "Twitter's Alex Payne quits, heads onto something new", namely http://banksimple.net/

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.

It's the only explanation I can come up with.

From a previous HN thread, here's the real reason at least for AmEx: http://news.ycombinator.com/item?id=1108650

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.

It's a good explanation, but it can only be valid if they store passwords in plain text. No financial institution would do that, right?

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.

Ahahahahaha! Yeah, right.

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.

Reply on news.ycombinator.com