z/OS PASSWORDS Keeping Up With the Times

z/OS PASSWORDS Keeping Up With the Times

Eric Rosenfeld

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

VIEW ALL ARTICLES

Why Major Banks and Financial Institutions are Growing Their Use of Mainframes

by Bryan Smith  on June 16th

There are many arguments that the mainframe is on its way out, and they all have one thing in common: they are all wrong. And nowhere is this truer than in the financial services industry, which is dominated by mainframes.

Isn't it curious that all major banks and financial institutions have mainframe computers at the center of their technology strategies? All of them. That's because mainframes are able to provide functionality and reliability that no other platform can match. These include:

• Transaction Power: Banks deal with a lot of data, and very few systems of record can match mainframes when it comes to transaction throughput. Simply put, big iron can handle the demands that major financial institutions throw at it.
• Analytical Speed: Transaction power is important, but it's only part of the equation. Mainframes let companies keep their data where it is (versus copying it several times into some warehouse), which dramatically reduces the amount of time it takes to access and analyze time-critical data.
• No Downtime: Banks can't afford to have system outages, and no platform is more reliable than the mainframe. I recently learned about a bank in Japan that has been using a mainframe since the 1970's without a single second of downtime. Its architecture allows for full software and hardware upgrades without an outage. For financial institutions, that's huge.
• Supports Mobile and Cloud: Mainframes may be 51 years old, but they are perfectly positioned to incorporate new technologies. Two of the most important for the financial industry are mobile and cloud because users require instant access to data no matter where they are. It's no longer a luxury. Mix in BYOD and it's pretty obvious that mainframes are perfect for the job.
• Integration: All of us have been through software integrations where two unrelated pieces of technology are supposed to work together seamlessly. Most of the time there are glitches because not everything lines up perfectly. Within a mainframe system, however, all of these can be resolved without requiring a system shutdown and restart.

IBM's Information Management System (IMS) was developed for the Apollo space program and has been a reliable component of mainframe data management ever since. The biggest recent growth for IMS has been in China, particularly for its largest banks. Many people outside of Asia might not know the names of these institutions, but they dwarf the largest banks based in the United States. And they are all powered by mainframes. Of course, they all have other platforms as well, but all of those other systems surround the mainframe as the system of record. On this side of the Pacific, large financial institutions are also growing their mainframe capabilities.  (Disclosure:  My employer is a development partner with IBM.)

When the world's largest banks decide to entrust their valuable data—not to mention their security and their reputations—to a particular platform, it's worth looking at why. The bottom line is that nothing has ever been able to equal mainframes when it comes to supporting global financial institutions. So, if you haven't looked at the mainframe in a while, maybe it's time to take a second look.

Publisher's Note: This Blog post by Bryan Smith was originally published in Network World (http://bit.ly/1cluQgy) and is used here with permission.

The Mainframe is a Witch!

by Chris O’Malley  on June 1st

The Mainframe Witch-Hunt

The Salem witch trials were an ugly moment in US history. A combination of groupthink, bad religion and confirmation bias led an entire community to act irrationally. And the results were not pretty. Twenty people—most of them women—were executed for being something we know they could not have been.

The mainframe has also been a victim of groupthink, bad religion and confirmation bias. That groupthink centers around the popular but clearly erroneous idea that mainframe is excessively expensive—and that its days are somehow numbered. The bad religion is a dogmatic faith in all things commodity compute. And confirmation bias is a refusal to look objectively at the facts of the matter.

Those facts include:

• Mainframes account for 68% of IT production workloads, but only 6% of IT spend (Source: Solitaire Interglobal)
• Over the past five years, costs at server-intensive IT shops have gone up 65% more than those of mainframe-intensive IT shops. (Source: Rubin Worldwide)
• Mainframe-intensive companies earn 28% more per dollar of IT infrastructure than server-intensive companies. (Source: Rubin Worldwide)
• Between 2005 and 2014, the ratio of mainframe MIPS to mainframe full-time equivalent employees has grown 351%. As a matter of historical significance, never in the history of IT, have so many owed so much to so few, as when it comes to dedicated, long-serving mainframe employees. (Source: Gartner)

In other words, mainframe economics have been proven to be better than distributed computing economics. Not by a little, but by a lot.

The Enlightened CIO

CIOs who don’t suffer from groupthink, bad religion and confirmation bias will recognize the mainframe for what it is: the world’s most powerful, scalable, reliable, secure and resource-efficient platform. The good news is that puts them in position to take unfair advantage of the mainframe’s power and superior economics to achieve things that less-enlightened peers cannot—especially when it comes to supporting technology intense requirements for rapidly growing mobile, transactional, and IoT workloads.

The bad news is that enlightenment doesn’t come without conflict. For one thing, resistance to groupthink requires a certain sort of intellectual backbone. You have to believe what you believe because it’s true—not simply because everyone else believes it. 

For another, you have to invest in the generational transfer of mainframe stewardship. One casualty of the “mainframe witch-hunt” has been the diversion of an entire generation of IT professional away from the world’s most powerful and secure compute platform. So if you’re going to keep leveraging the platform as your veteran mainframe talent heads into retirement, you must transform your mainframe culture and your mainframe toolkit.

Neither of these things comes easy. But if you have a mainframe and the will to fight for what's right, you will be able to do more for less—and with far greater confidence—than those who have been crying “Witch!” for far too many years.