Why are we still using COBOL in so many critical places (like in banks)? Isn't it a threat to security?

Answer 1

COBOL is just another programming language - but for the most part - running on mainframes or "middleware" - close to the database, providing "information" - is not responsible for dealing with front-line security needed nowadays on the web or at a bank office (using the example provided).

At the point most COBOL services come into play nowadays, security has already been performed a few times already (including a service "authenticating" to the COBOL request).

*** A user logs into their bank account on a website That will use tcp/ip/ (secure) https: protocool which will encrypt the information so that - in theory - the communication between the user's machine and the website is secure. Normally - the programming language on the front-end handling the login credentials is not COBOL - but rather java, .NET, phython, and javascript (i.e. nodeJS). Those services may call a COBOL routine to check the database to perform authentication, but those calls are usually "secured" in-house.

*** Regardless of the language - any decent security mechanism to log in a "user" will use a one-way hash - which means unless the user id and password combination "hashed together" isn't correct - it will never be correct. If you call into your bank and ask "what's my password?" - if they can tell you that - it's not a one-way hash (and you should find another bank - I will just leave it at that without getting into details).

*** Once your id/password has satisfied the match ("you are who you say you are") - and you want to view your bank account - is where normally a language like COBOL comes into play; the front-end language (say, java) on the "website front-end" sends a credentialed call to a COBOL service ---- "I am acting upon user "X" - and my credentials to ask you questions is "user Y" (the java to COBOL authentication process, usually an in-house credential) - will COBOL asking a database what the user's bank account details are.

All said and done, the programming language used to access the database has gone through multiple layers of authentication and authorization to allow access - at this point, the language in use to access the data itself / process is really not that important in terms of security - the front line security has been taken care of - and for a solid security layer - the database storing the actual data is strongly encrypted.

The larger issues for security is more preventing holes in the multiple layers of security I've discussed, as well as ensuring the communication between the layers (and the database itself) is secure/encrypted.

Most security breaches performed today are phishing (pretending to be a legit "banking" website - where a user gives up his/her id/password), or database breaches where the "entire" set of data is pulled down, becuase the database itself wasn't encrypted and can be easily viewed. There are still large companies today that probably have unsecured id/pwd credentials; a company I worked for in the past didn't consider that a big deal and got hacked... too easy....

Big security breaches nowadays are normally caused by good phising (thinking you're logging in with your id/password) to a legitimate site (where the criminals capture your login information, and then use that information on the legit site), or massive database breaches - where identifying information is left unsecured/unencrypted on the database.

If a bank is using COBOL services to access and provide information to other services, I'm no more concerned about the language used in that layer as I am the front-line / database-encryption security.

Hope that helps...