How to avoid hardcoding credentials inside a COBOL program?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.