From their point of view, if someone can read the database on their mainframe, that's already doomsday. They put all their security outside that perimeter, but no further layers like encrypting table columns inside.
They store passwords the same way they've always stored PIN codes (where encrypting would be pointless): there's a ALPHA(8) field right next to the NUMERIC(4) field for your PIN. Those design decisions are from an era where adding an extra VARCHAR(64) to store a MD5 password times 100 million accounts cost real money. It was probably the right decision.
Rather than sneer at the older generation, try to see the constraints they worked within. It opens your mind to imagine what "right decisions" now will seem silly to later generations. Non-GC languages with threads kludged in? Program syntax limited to ASCII? Silicon? IPv4 & NATs?
Online banking system have not been around that long. I do understand banking systems (the legacy stuff) and online banking (the newer front end stuff) particularly well as I built some of them. When I say built, I mean the company I founded wrote the code and I was the lead architect for what was used in many online banking systems.
Access to your accounts online should entail a system just for online access which is separate from and has a tightly controlled internal interface to the legacy bank system. I realize some banks may not have done it this way.
I spent my early career integrating with and sometimes replacing legacy mainframe systems. I have much respect for the old constraints programmers had. If a bank gets their online access wrong for anything written in the last 10 to 15 years its probably due to a decision to not architect the solution properly rather then a programmer being ignorant.
Comments
From their point of view, if someone can read the database on their mainframe, that's already doomsday. They put all their security outside that perimeter, but no further layers like encrypting table columns inside.
They store passwords the same way they've always stored PIN codes (where encrypting would be pointless): there's a ALPHA(8) field right next to the NUMERIC(4) field for your PIN. Those design decisions are from an era where adding an extra VARCHAR(64) to store a MD5 password times 100 million accounts cost real money. It was probably the right decision.
Rather than sneer at the older generation, try to see the constraints they worked within. It opens your mind to imagine what "right decisions" now will seem silly to later generations. Non-GC languages with threads kludged in? Program syntax limited to ASCII? Silicon? IPv4 & NATs?
Online banking system have not been around that long. I do understand banking systems (the legacy stuff) and online banking (the newer front end stuff) particularly well as I built some of them. When I say built, I mean the company I founded wrote the code and I was the lead architect for what was used in many online banking systems.
Access to your accounts online should entail a system just for online access which is separate from and has a tightly controlled internal interface to the legacy bank system. I realize some banks may not have done it this way.
I spent my early career integrating with and sometimes replacing legacy mainframe systems. I have much respect for the old constraints programmers had. If a bank gets their online access wrong for anything written in the last 10 to 15 years its probably due to a decision to not architect the solution properly rather then a programmer being ignorant.
Encrypting passwords protects against insider attacks also, so it would still be a benefit.