[Someone1234]

Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc).

For a specific example Oracle Database has a very restrictive list of characters allowed in a user password. If you're using Database Users behind the scenes (even if not directly, but via an Oracle integration) you're subject to those same restrictions. Up until Oracle 11g passwords were also limited to 30 characters and a few releases before that were case-insensitive (!).

Is this a good reason? I'd argue, no, but I've worked at tons of organizations where "things that don't make sense" often have an explanation even if it isn't an explanation you're happy with. We should definitely push companies to use cryptographically secure one-way hashing functions with salts, and adjustable difficulty.

[tzs]

> Typically, they're using legacy software to store the password itself (e.g. database, mainframe, etc)

I've heard banks and other financial institutions use the "our ancient mainframe only allows 8 characters in account passwords" excuse or "our ancient mainframe database can only handle 8 characters in the password column", and find it extremely hard to believe.

First of all, I find it hard to believe that each customer has a user account on the mainframe, and so the mainframe's restrictions on account passwords is irrelevant. Your banking account is going to be entirely something defined by the database.

Second, I find it hard to believe that they are running their web server on their ancient mainframe OS. The web server is going to be running on something more modern. Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system. Your user name (if their online banking uses something other than you account number) and you password for online banking should be entirely handled on the Unix or Unix-like or Windows Server that is running their web-facing stuff. The ancient mainframe stuff should never see it.

[Someone1234]

> I find it hard to believe that each customer has a user account on the mainframe

Why? Do you actually have any experience in this area? I do, and I can tell you, they do exactly that. Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization. Migrations are an absolute nightmare.

> Users have to go through that to do online banking, and the account system on that can be totally separate from whatever account system is running on the backend banking system.

It can be, but it isn't. Thus, the problem.

Honestly this type of "hardly believe" take is what every new employee right out of college (or myself 15 years ago) when they come up with ten thousand "simple" ideas for improvement without any organization, political, or system understanding. Then they act confused when their ideas aren't instantly implemented, because they don't even understand what it is they're proposing or why it is complicated.

Banks have been trying to get off of mainframes for 30-years or more at this point, spent tens of millions of dollars, but had someone just told them to "run a web server in front of it" this could all have been avoided.

[tzs]

> Then multiple systems integrate with that mainframe, often using the user account as the unique identifier for the entire organization.

How do the multiple systems communicate with each other and with the mainframe?

[Someone1234]

Depends on the company. Web API (with or without VPN), VAN + EDI, Dial Up Modem (not joking), Scripted SSH/Insecure Terminal, FTP/SFTP/FTPS w/XML or Scripts or EDI, etc. Some communications/integrations are bleeding edge, some are older than I am. It really varies.

Then you have multiple half-measure attempts at migration away from the mainframe, so you wind up with a half-built Java layer and a half-built [Large Contractor] bespoke system.

[tzs]

Stepping back from all the details, somewhere in all their collection of assorted ancient systems, hacks and kludges from previously failed attempts to migrate to something newer, and whatever else they have, there is something that presents a public facing web site that customers can log in on for online banking. (I'm only talking about companies that offer web-based online banking, not companies that want to add online banking to a system that doesn't already have it).

There is something that handles the user's submission from that site and records somehow that the user is logged in, and directs the user's browser to some site that can somehow get their account information, balances, etc, from whatever that is stored, and can handle form submissions that request operations on those accounts such as transfers, bill pay, and such.

What I don't understand is where the difficulty would be in making it so customers do not talk directly to those web-based things, and instead talk to a web front end running on a separate, reasonably modern Unix, Unix-like, or Windows Server and that server talks those older web-based things. It could even talk to them over HTTP looking like a browser to the older components. The online banking front end would not have any direct integration with the rest of their systems. It would just go through the same interfaces they already are using to support online banking.

Heck that is essentially what Plaid does for banks that don't have a useable API. They log in to the bank's online banking site with the customer's credentials and then screen scrape to get the account balances. That has got to be a nightmare for Plaid because they have to deal with many different banks, any of which might make changes that break their scrapping with no notice.

A bank essentially doing its own Plaid that just has to work with its current online banking site should be a lot more doable.

[vidanay]

If you're storing a raw password in a database, limiting specific characters is waaaay down on the list of things you're doing wrong.

[Someone1234]

My post said nothing about storing "raw passwords in a database." Therefore, it is unclear what you're replying to.

I am talking about Oracle Database Users and Oracle Database's password limitations therein. The reason for Oracle Database's password restrictions isn't to do with how they're stored on disk (which is secure as if 12c[0]), it is to do with how they were implemented originally (i.e. passwords are implemented as database objects, and database objects have max lengths and other naming rules which apply to passwords).

[0] https://seanstuber.com/how-oracle-stores-passwords/

[barrkel]

Most likely what's being talked about here is using Oracle to track identity across accesses to data on a per user basis, for permissions and auditing, and that piggybacking on Oracle's own password management with its own restrictions.