3 ms·

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 interface

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.

tzs 14y ago
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.
- ricardobeat 14y ago
  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.
iuguy 14y ago
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.

tzs 14y ago

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.

ricardobeat 14y ago
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.

iuguy 14y ago

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.