How to secure store password in a JCL FTP?

Question

I have the following code to send a file through FTP using JCL:

//FTP00001 EXEC PGM=IKJEFT01,DYNAMNBR=50         
//OUT      DD   SYSOUT=*                         
//AMSDUMP  DD   SYSOUT=*                         
//SYSTSPRT DD   SYSOUT=*                         
//SYSIN    DD   DUMMY                             
//SYSPRINT DD   DUMMY                             
//OUTPUT   DD   SYSOUT=*                         
//SYSTSIN  DD  *                                 
123.234.345.67
myuser1
p4ssw0rd
ascii
cd infos
PUT 'EF35.LMINFO.D180203' info_180203.txt
QUIT
/*

It works like a charm, the problem is that I don't want to put the credentials hardcoded inside the JCL. How could we hide them so anyone who has access to the JCL can't see the connection details? I'd like to hide the credentials from the output too, but note I still want to see the rest of the info: bytes transferred, possible error messages, and so on.

I thought in putting the SYSTSIN content inside a file, but I'd face the same problem: anyone who has access to the file, will see the user and pass. Therefore, what is the best method to sort this out?

Inclined

not sure why this is getting down voted, its actually a valid question and concern when FTPing with JCL – Ninetieth

Answer 1

The way I have seen it done is like this:

//FTP00001 EXEC PGM=IKJEFT01,DYNAMNBR=50         
//OUT      DD   SYSOUT=*                         
//AMSDUMP  DD   SYSOUT=*                         
//SYSTSPRT DD   SYSOUT=*                         
//SYSIN    DD   DUMMY                             
//SYSPRINT DD   DUMMY                             
//OUTPUT   DD   SYSOUT=*                         
//SYSTSIN  DD  DSN=AA.SOMETHING.LOGIN,DISP=SHR
//         DD  DSN=AA.SOMETHING.FTP,DISP=SHR
//         DD  DSN=AA.SOMETHING.LOGOFF,DISP=SHR

where AA.SOMETHING.LOGIN would contain

123.234.345.67
myuser1    <- replace with ACID for this job 
p4ssw0rd   <- replace with password for the ACID

AA.SOMETHING.FTP would conatin

ascii
cd infos
PUT 'EF35.LMINFO.D180203' info_180203.txt

AA.SOMETHING.LOGOFF would contain

QUIT

This JCL would run via a batch ACID and only the ACID would have read/write access to the AA.SOMETHING.LOGIN file. So the FTP server would need to add the ACID as a user. That is really the only way to do it. You are right though, anyone with access to AA.SOMETHING.LOGIN can see the credentials, but because we separated the login information from the FTP commands, there is no reason to need access to the login files unless the username/pass or the IP address changes. So you would be able to change anything in the files you have access to. You could also take it a step further than put the IP address in a separate dataset so then you can edit/view literally anything except the login credentials. That would look like this:

//FTP00001 EXEC PGM=IKJEFT01,DYNAMNBR=50         
//OUT      DD   SYSOUT=*                         
//AMSDUMP  DD   SYSOUT=*                         
//SYSTSPRT DD   SYSOUT=*                         
//SYSIN    DD   DUMMY                             
//SYSPRINT DD   DUMMY                             
//OUTPUT   DD   SYSOUT=*                         
//SYSTSIN  DD  DSN=AA.SOMETHING.SERVER,DISP=SHR
//         DD  DSN=AA.SOMETHING.LOGIN,DISP=SHR
//         DD  DSN=AA.SOMETHING.FTP,DISP=SHR
//         DD  DSN=AA.SOMETHING.LOGOFF,DISP=SHR

This also allows you to change the server, FTP commands and logout/cleanup all without having access to the login credentials.

The only real downside to this is if you ever need to update the login credentials, you either need to:

1. Request access to the file
2. Write another JCL that will run with the ACID that has access to that file to update it

Even with that in mind, I still think this is the best way.

Ninetieth

It also allows you to use the same Login file for multiple FTP's. So if the password changes, you only need to change one file – Disaffiliate

Awesome! Two further questions: 1) Will user and pass be displayed in the log output? 2) Is it possible to encrypt the AA.SOMETHING.LOGIN using RACF or similar tools? Just to provide a second level security. Thanks! – Inclined

when I tried it, the USER showed up in the SYSOUT, but the password did not. I have never tried the encryption, but I assume it wouldn't work because there would be no way to decrypt it when passing it in to the FTP step (without decrypting it and copying it to another file which brings us back to here). – Ninetieth

Perfect, thank you! I can see a potential improvement here, look: ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/… What are your thoughts? – Inclined

I agree with you harrison4 – Soul

Our site follow something similar to this answer when it comes to storing the credentials for FTP. – Patrolman

Answer 2

harrison4 pointed out that the IBM Communications Server has an architected form of this solution that can use either a dataset or a USS file. It is documented in the "z/OS Communications Server: IP User's Guide and Commands" manual to which harrison4 linked in his comment:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/netftp.htm

It may go without saying, but I'll say it anyway. It is always bad practice to store passwords in datasets or files unless they are encrypted (not encoded, encrypted). If you must do this, be sure that the file permissions or security manager profiles restrict access to the file/dataset as much as possible.

Soul