This was forgivable 30 years ago. It was bad practice 20 years ago. Someone could have demonstrated leadership and developed a ten year plan to fix their legacy problem then.
They did. And Pi factor came in. And budget was cut because those pesky fintech are a threat, and clearly money was better spent on a more modern offer than on those "security" concerns.
And yes, it's possible to add 2FA to the front layer. However, the remnants of COBOL code running on the mainframe for the last 25 years weren't designed to handle passwords length 9 or more, and the last guy who knew how that code was built has retired some 15 years ago.
It was written when the cost/benefit calculation of writing it involved "downsizing" thousands of clerks who were doing the job manually.
It can't be replaced because the cost/benefit calculation of replacing it does not involve anything like those kinds of numbers. The benefits of avoiding even a major security incident just don't compare to the costs.
Y2K taught me this. Nothing has changed since.
TSB customers have learned how painful it can be if the migration of a core banking system fails: https://www.independent.co.uk/news/business/news/tsb-it-fail...
And there's the real problem:
The banks will save their money and stick with plaintext if they can get away it.
Put another way, it's an incentive problem.
With a six-digit PIN.
See
- https://www.labanquepostale.fr/ > "Me Connecter"
- https://lcl.fr/ > "Mon Espace"
- https://particuliers.societegenerale.fr/com/icd-web/cbo/inde... > 12345678 > Valider
My experience: built a Web site/app for: a) major bank b) major corp, back in the days when Web presence was kind of a new thing. ~15-20 years ago.
You build a new (Web) app and treat the legacy system (happened to be some mainframe) as a backend or whatever. Add new tables to hold user's credentials, email addresses, and whatever else. Link the "new" credentials with the old "account id on mainframe" or whatever. Not really rocket science.
BTW - there was no such thing as an "old password table with max 8 character", not for retail customers. Retail customer did not have a password, or email.
Adding a table to hold users' credentials doesn't really solve the problem that is being discussed, which is storing users' credentials. All that does is add a new attack surface, stealing the new credentials, and the original credentials are still in the same position.
?
Not sure if serious.
There is no technical excuse for not hashing passwords.
Oh, I am sure they do. The big question for this thread is: how come this "8-character all-uppercase" password is a thing in States, but less of a thing in e.g. Europe.
There was a forced password reset that enabled real password policies.
A lot of the mainframe systems running large organisations were written more than 30 years ago and are still the core of the business, so their limitations are the constraints everyone else works around.
> Someone could have demonstrated leadership and developed a ten year plan to fix their legacy problem then.
The large project I work on is 12 years into replacing the mainframe platforms which have run the business for 45+ years, and we're not even halfway through the portfolio. Do not underestimate the complexity of these mainframes and the time & cost needed to fully replace them.