I’ve been looking into login on to Zowe and z/OSMF, and have realised how complex it is to set up secure logon.
An obvious fact about real life
If someone has access to your machine, for example a hacker, then they have access to your files, and data in virtual storage.
I cover
A lot of the time it is not difficult, but you need to handle the edge cases. When there are multiple dimensions to the problem, the edge case becomes the corner case, and this is where it gets really hard.
I use the expression is not secure. Being secure is relative. If your machine is air gapped with no external access, the machine should be secure. If people can access your files, perhaps on a shared machine, or a hacker can accessed your machine, I would not consider this secure.
The simplest case of logging on manually from a client machine to the server
Of course you use a TLS session to ensure the session traffic is encrypted.
You can type the values into the userid and password fields. It works, simple. If I disconnect and reconnect, I need to re-enter the userid and password
If I am using more than one back end server, I’ll have to enter the userid and password for each system, while the session is active.
Once the userid and password have been used, the fields in memory should be overwritten (but I doubt if this is always the case), to minimise the time window when a hacker extract the values from memory.
The simple case of logging on from a script from the client to the server.
You will not be there to enter the password so it needs to be stored.
The script may prompt you for the userid and password. You enter the information once, and it keeps them in virtual storage, and does not write them to disk. At the end of the session these values need to be overwritten in case a hacker is wandering round your system.
The application may write the information to disk – and we immediately hit a major problem. If a hacker has access to your system, then they can access (and copy away from your machine) the file where the password is stored. On Linux I displayed the contents of the “secure store” with a few lines of Python. I believe it is the same for Windows and Apple machines. (If your userid needs access to the secure store for something, a hacker thread running with your userid can access the store).
We have quickly seen that the use of a password stored on the machine is not secure.
Use of a certificate
As part of the TLS handshake there is a private key kept on the local machine, and a public key is sent to the partner.
Trusting a certificate
As part of setting up the public key, I send the public key to the server. The server’s Certificate Authority does a checksum of the public key, then encrypts the checksum with the server’s private key. The public certificate, encrypted checksum and the CA’s public key are sent back to the originator.
When the public certificate is used as part of the TLS handshake, the server does the same checksum calculation as before on public certificate, and saves it momentarily. It takes the encrypted checksum from the payload, decrypts it, and compares the two checksum values. If they match, then the client’s certificate can be trusted and has not been changed. Therefore the certificate is trusted (for a given level of trust) to represent the end user.
My program has access to my private key – so authenticates as me
As part of the handshake data, the client encrypts some data using its private key, and sends this to the server. The server uses the public key it received, and decrypts this value. If the decrypted data matches what it is expecting, then this is proof that the client has the private key and is who they say they are.
The server can then use the mapping of “name in the public key” to a userid, to determine which userid the requester should run under.
Once this is set up, the client can connect to the server without specifying a userid and password.
There is a proposal to reduce the validity time of personal certificates from over a year to 47 (or less) days. This reduces the time window when a certificate can be used.
This is great … but
If your private key is stored on your disk, a hacker can steal a copy of the file and impersonate you. So once again this is not very secure.
Use a private key – external to your computer
You can get a dongle, such as a Yubikey which keep the private key secured on a detachable USB dongle. To use it, a request is passed to the dongle saying “please encrypt this data”. It encrypts the data, returns it, and it can be sent to the server. You cannot extract the private key from the dongle.
To use this for authentication you physically need the dongle. If someone has control of your machine, they can use this dongle when it is plugged in. If they just have a copy of your files they cannot use the dongle, and so this is secure.
If you remove the dongle when you are not using it, we have a secure solution, until you plug it back in! Most people may forget and leave the dongle in all day.
I’ve been to sites, where the private key is stored on their badge. When they want to authenticate they put their badge on a badge reader and authenticate. This is awkward, so they immediately take their badge off the reader after authentication.
Setting up these external key stores is not trivial.
Use of Multi Factor Authentication(MFA)
One of the main approaches to MFA is
- something you have
- something you know
MFA is often used in applications such as online banking.For some transactions you will have a code sent to your email address. Something you know is your application password, something you have is the code sent to you. To use the service, an application password and access to your email is required.
MFA can also use one time passwords – so if someone is monitoring your network traffic they will not be able to reuse the one-time-password.
You can get the one-time-password generated from your badge, a dongle attached to your machine, or an application, such as an authenticator application on your phone. Once these apps have been configured to the back-end, you can press a button and get a one time code.
To logon you may need your normal logon password (which you change monthly) and the one time code from the MFA device. You might just need the one-time-code – depends on how the environment has been set up.
This is great for you logon to a backed and stay connected. If you have script, or are using multiple back-end servers. This becomes impractical. You need a new one-time-code each time you logon. This can be automated if the MFA device is attached to your machine, but not if you are using a mobile phone application.
One small problem is when the user’s password has expired. They are prompted to change it, and now need another One Time Password – and they may have to wait for a period (seconds) before a new one is generated.
JSON Web tokens
See Are JSON Web Tokens secure? – Yes if used properly.
A JSON Web Token(JWT) provides a time limited key, and so avoids the problems when changing a password. Some of the concepts are similar to a certificate logon, but with a limited validity, from minutes to hours.
With RACF these are known as Identity token. (Having a different name, means RACF development can extend the support to cover additional tokens types.)
A JWT has three parts
- Information about the JWT. This JWT has used an RSA certificate, and algorithm SHA256.
- Identity information. The userid is…, it was issued by ( z/OSMF, or SAF), at this time…. and is valid until….
- The above parts are check summed, and the check sum is encrypted using a private key.
The above 3 parts are base 64 encoded, and joined together with a ‘.’ between them.
Once a JWT token is created, it is valid until it expires. You need to consider if you want a JWT to be valid for a few minutes, or all day.
You create (or have the system create for you) the header and the payload. You calculate the checksum, and encrypt the checksum with the private key.
The parts of the JWT are assembled and sent to the partner.
The partner uses its copy of the public key, and checks that the checksum matches what it expects and, if it matches, can use the information in the payload part. This validation could be a call to a RACF service, a https request to a server, or Java.
Once the JWT has been validated, the server can use the information in the payload.
You do not want to use the userid in the JWT directly, because the userid COLIN on one system has no authority, but has super user authority on another system.
With RACF you can map a userid string to a RACF userid using profiles defined with the RACMAP command. See the r_usermap service.
While the JWT is valid it could be used by a hacker.
Overall
It looks like there is not one good solution to cover all cases.
Someone said “assume your machine will be hacked. Minimise what damage they can do”. This may be as simple as turning your machine off overnight, so the hackers cannot control it
The solution for scripts may be different to people logging on.
You may want to have a userid just for scripts, which has only enough authority and permissions to work, and no additional permissions.
You need to consider the options and risks, and not just sleepwalk into having an insecure system.
ColinPaice 