CODEWITHSUNDEEP
securitypasswordscobolmainframejcl
mllamazares
mllamazares

Reputation: 8166

How to avoid hardcoding credentials inside a COBOL program?

I have the following code to connect to an external DB inside a COBOL program:

MOVE 'I2SFG04'  TO WK-USER
MOVE '12345'    TO WK-PASS

EXEC SQL 
    CONNECT TO :WK-EXT-MACHINE 
    USER :WK-USER 
    USING :WK-PASS
END-EXEC.

But as you can guess, I don't want to hardcode the user and pass within the COBOL program. So is there a secure way to store them so anyone who has access to view the COBOL program can't see the credentials?

My first approach was to create a file (RACF protected) with the SYSIN content, so the COBOL program can load it up, but it won't be displayed in the source code. Something like this:

//STEP001  EXEC PGM=IKJEFT01
//STEPLIB  DD DSN=I2SJR04.SYS.DBRMLIB,DISP=SHR
//SYSIN    DD DSN=EF35.PRIVATE.DB.LOGIN,DISP=SHR
//SYSOUT   DD SYSOUT=*
//SYSTSIN  DD *
    DSN SYSTEM(SSID)
    RUN PROGRAM(MYCOBB) PLAN(PLANNAME) -
    LIB('I2SJR04.SYS.LOADLIB')
    END
/*

Content of EF35.PRIVATE.DB.LOGIN file:

I2SFG04
12345

Is there a better way to handle this kind of situations?

Upvotes: 6

Views: 927

Answers (4)

Valerie R
Valerie R

Reputation: 1817

A more sophisticated and secure solution would be to write a short assembler program that fetches the user and password from the security system (RACF, ACF2, Top Secret) itself.

Here's a narrative if you have the IBM RACF product as your security product: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ichd100/passret.htm

What this approach does is put the logic of whether to allow the password to be fetched in the hands of the security administrator, rather than the programmer. You can show the world your source code, but if the security system doesn't grant access to the credentials, it doesn't matter what a user can see. Plus, this type of thing can usually be audited, so you can pretty easily get a complete list of every time the user/password was referenced.

Upvotes: 4

James Anderson
James Anderson

Reputation: 27478

If its an IBM zOS mainframe you do not need to supply any credentials.

Your connect will use the user-id of the running job.

You just need to tell your DBA what the JCL user id the job will run under -- he will then grant access to the plan you are using.

Upvotes: 2

SaggingRufus
SaggingRufus

Reputation: 1834

I am going to do my best to answer this. I have not worked directly with calling a database in COBOL. We have a bunch of server programs that are maintained by another group, but I did do some digging. This is how we do it using a DB2 database. I also don't really know what we are doing behind the scenes, so you mileage may vary. Here is how I understand it:

We have a JCL that execute the program that would look something like this:

//STEP01 EXEC PGM=PGM001                                    
//*                                                                     
//*------- DB2 Plan ------------------------*                           
//DSNPARMS DD DSN=XX.DBNAME.DBPLAN.JOBNAME,                               
//            DISP=(MOD,DELETE,DELETE),                                 
//            UNIT=SYSDA,                                               
//            SPACE=(TRK,(0))                                           
//*                       
//INPUT (input files for job)
//OUTPUT (output files for job)

The DSNPARMS file itself is empty, it is used as a place holder that has all of the relevant information required to call the data. The structure of the file name is SystemResourceCode.DatabaseName.PlanName.JobName

From my understanding (for a DB2 database), all that is required is to have the plans and collections set up accordingly and have that all tied to an ACID.

So basically the ACID is tied to a database collection the collection contains a set of database plans.

A database plan points to the database packages. So in short, if the collection associated to your ACID has the proper plans in it, you should be able to access the database without login credentials because the DBMS knows that based on the ACID here are all of the plans you actually have access to.

This is also means that the TSS access will need to be set up so that whoever needs access to run a JCL with that ACID can run it.

I don't really have any sample code of the backend, but I hope this explanation was enough to get you past hardcoding credentials somewhere. Talk to the database guys and ask them about setting up plans and collections. They might be able to help you from there.

Upvotes: 0

MikeT
MikeT

Reputation: 56958

The only pitfall I can see would be if someone where to recode and recompile the program to say output the details.

So perhaps you could take the additional step of using a RACF protected program library into which the program is compiled.

Upvotes: 1

Related Questions