z/OS PASSWORDS Keeping Up With the Times
Passwords have been protecting user access on the mainframe since the ’70s. They are ever changing to keep up with the evolving environment in which they are used. This article will discuss how RACF password processing has been updated over time.
In the Beginning
When passwords were introduced in RACF, they were eight character strings, allowing combinations of uppercase letters, numbers and three special characters: #, $ and @. The original characteristics were taken from TSO. The mechanism used to keep the casual observer from seeing the passwords in the RACF database was masking. This format was acceptable at the time, but as MVS grew it quickly became evident that RACF’s approach to passwords required periodic enhancement.
A Brief History of RACF Passwords
It wasn’t too long before it was determined that simple masking was not a sufficient method of protecting passwords and in RACF V1R6, DES was added as an optional method for encrypting passwords stored in the RACF database. This was made the default in RACF V2R1.
The next enhancement was to expand the choices users had and allowed lowercase letters in the password, enabling mixed case passwords in z/OS V1R7. The addition of these characters greatly increased the size of the pool from which passwords could be chosen.
Although passwords had been enhanced recently, there was a demand for longer passwords, so shortly after mixed case passwords were allowed was the introduction of the password phrase in z/OS V1R8. This attribute of a user definition could be used as an alternate authenticator. A password phrase was defined as a 14 to 100 character string that could be used in place of a password by applications. Any character that could be entered from a keyboard for use by a command could be specified. It had a number of built-in syntax rules:
• Maximum length: 100 characters
• Minimum length: 14 characters
• The user ID (as sequential uppercase characters or sequential lowercase characters) is not part of the password phrase.
• At least two alphabetic characters are specified (A - Z, a - z).
• At least two non-alphabetic characters are specified (numerics, punctuation, special characters, blanks).
• No more than two consecutive characters are identical.
Password phrases could be used by applications in the same way passwords were used as authentication strings. Both password and password phrase were part of the user’s definition so both were available for use and an application could choose which to accept.
Although the minimum length of the password phrase was chosen because of its encryption strength, shortly after implementation it became quite obvious the gap of length between eight and 14 was going to be a problem. The ability to have lengths in the gap was allowed via a password phrase exit. If this exit, ICHPWX11, was implemented on the system, shorter phrases could be defined, assuming the exit would enforce additional rules to ensure the strength of the phrases.
What’s New With Passwords?
In the early days of RACF, MVS systems had very little exposure outside the enterprise and securing the environment was mostly handled inside the walls of the installation that housed it. With the expansion of z/OS into the connected world of today, the view of security is much wider and is expanded to take into account the entire network of computers with which an enterprise interacts.
With this expanded view comes a stronger need to protect security definitions from outside eyes. The RACF database should be one of the most highly secured resources in an installation. Even with the best planning to protect the data within, there is always a chance there will be a breach of this security.
To strengthen the security of RACF authentication strings, updates have been introduced via PTFs for z/OS V1R12, V1R13 and V2R1.
• The first update is to allow additional characters in passwords. More special characters can be used when defining passwords. The 14 additional characters are . < > + | & ! * - % _ ? = :
If an installation allows these characters in passwords, they greatly increase the password space the users can choose from.
• The next update allows for a user to have a password phrase without requiring a password. This will enforce that users without passwords can only use phrases for authentication. Before this ability was added, it was up to the application to enforce which authenticator, password or password phrase could be used. If the application allows both, then the user can use either for authentication. This support enables the ability to remove the weaker authenticator when it is not needed.
• The most dramatic update is the addition of a new encryption method used when storing and verifying RACF passwords, Key Derivation Function with AES or KDFAES. From this point on, my references to password regarding encryption also apply to password phrases. This encryption method used for passwords is much stronger than DES and operates by appending random data to the password, iteratively hashing it thousands of times with SHA256 to generate a key, AES encrypting the ID of the user using that key and storing the result. Using this method makes the ability of someone to derive the clear text password from the encrypted stored value much less likely and because of the appended random data makes pre-encrypted values for comparison via a rainbow table impossible.
The ability to convert the existing DES passwords and password histories is also available via the ALTUSER command to enforce the use of the new algorithm without requiring users to change their passwords. Conversion does not apply to password phrases.
• In support of the additional password encryption updates, a new check was created for the IBM Health Checker for z/OS. It reports on the state of password encryption being used on the system. If the very weak password masking is the method in use, an exception will be raised. The check will also highly recommend the activation of the new KDFAES encryption method if it is not activated.
This check was made available prior to the availability of the new encryption support to warn of the use of password masking and to assist in the migration to the new KDFAES algorithm, when available, by flagging password processing that could hinder moving to KDFAES.
What Does This Mean to Me?
Now that we know about all this support, what now? In a perfect world, the system settings would be configured to allow passwords to have the original set of characters, lowercase characters and all the special characters. The new health check would find no issues regarding password processing. All applications would accept password phrases and most, if not all, users would not have passwords. And last, but not least, KDFAES would be activated as the encryption method in use on the system and all users would have their current password, password phrase and associated histories in the KDFAES format.
In the real world, each RACF environment should be configured with what will be effective and functional. As many of these options that can be implemented without impacting the applications that are running should be activated. Some of the questions that need to be considered are:
• Which applications are in use by which users?
• Do all applications support mixed case passwords?
• Are there specific special characters in passwords that cause issues with a particular application?
• Which applications support password phrases?
Conclusion
RACF passwords are evolving over time. They have increased from an eight character maximum masked value to up to 100 characters stored as a derived AES value, allowing for many more symbols within. They have allowed users more choice in values and are much more fortified than in the past. How will the password change in the future? Only time will tell.
Eric Rosenfeld, CISSP, joined the IBM MVS support team (Levels 2 and 3) in 1985 as a software engineer and has been developing security products for more than 20 years. He is currently a designer and developer for RACF. Email: rosenfel@us.ibm.com
No comments:
Post a Comment