IBM Mainframe Forum

I'm working with a client who is using z/OS V1R12 with DES for password checking. As some may know, DES is not a very strong method of "securing" much. My client doesn't seem to want to use LDAP for authentication and I'm wondering if anyone has created a custom exit for RACF that implements AES (or similar) instead of DES. Anyone?

The reason I ask is that I'm an auditor and I'm not comfortable with the fact that the "secret" stored in the mainframe uses a known plaintext (the userID) and a known algorithm (DES) which allows tools to quickly recover passwords. Yes, I get it, the passwords aren't ever stored on the mainframe. The issue is, the data required to gain access; both the userID and password be (relatively) easily obtained. Especially if password lengths and complexities are restricted for interoperability reasons.

Thanks in advance for any suggestions!

-Parsec.

this is a Forum dedicated to beginners and students,
You might get better answers if You investigate/ask in one of the RACF specific user groups

did You search the IBM REDBOOKS for additional info ?

• The data format of the RACF database is not widely known, so locating the encrypted passwords is not so easy.
• I don't know if RACF uses DES for its passwords. In any event, as I understand it, even with knowledge of the key it is not possible to translate the encrypted password to plain text. RACF encrypts the plain text password and then compares the encrypted form of the password with the encrypted password in its data base. If they match, RACF is happy. So it is not necessary for RACF to translate an encrypted password to plain text.
• Since the plain text is very restricted in length, encryption crackers have very limited possible text to use to test if the cracked passwoord is valid. Granted, the password phrases from z/OS 1.7 on have a larger plain text to use, but I think the same general rules apply.
• Do not allow users to have read access to the RACF database and its backups. That way the password cracker has essentially no data.
• Set a low limit for logon attempts and bad password attempts. That way the password cracker will have a difficult time doing brute force attacks.

From time to time an IBM RACF expert looks in here. Perhaps he can provide more insight than me.

I think IBM's comments in the V1R12 Security Server RACF System Programmers Guide manual pretty thoroughly and clearly refute your concerns:

The RACF® DES authentication algorithm provides a high level of security because it supports one-way encryption only; it does not support the reverse process. In addition, it does not store the password it uses as the encryption key. For these reasons, the reconstruction of original data is virtually impossible. However, make sure that users do not have READ access to the RACF database unless their jobs require it.

As far as I am aware, the user id does not get used in the DES algorithm -- only the password, which is stored only after going through the one-way encryption process. As long as the site sets the limit on access attempts low, and there is very limited access to read the RACF data base, I see no way for anyone to crack any password. I think your concerns are founded upon an incomplete understanding of the security mechanisms used, and should not be considerd as any kind of real issue.

This does seem to be a situation where the auditor has no clear understanding of the system being audited. This seems, in my experience, to be a common failing.

In addition, it does not store the password it uses as the encryption key.

It has to get the key from somewhere! Actually, I think it computes the key by hacking the userid. This means each userid hopefully has a unique key, provided, of course, that's the effect of the randomizing hack.

No one will argue that DES is that strong any more, but it is still relatively hard to crack.

The algorithm takes the username, encrypts it via the DES algorithm and uses the password as the key. The resultant ciphertext is stored in the RACF database.

When a user logs in, the user enters their userID and their password. The mainframe takes the userID, encrypts with DES using the password as the key. The mainframe then compares the result of this new ciphertext with the ciphertext stored in the database. If they match, the mainframe lets the user in.

The issue is, the userIDs follow a standard and DES has a very weak keyspace, therefore password crackers like John the Ripper have an easy time of discovering the password.

So, unfortunately DES does not meet requirement 8.4 of the PCI DSS, the credit card security standard required by the card brands.

Yes, steve-myers, I don't have a clear understanding of mainframes. Over the past 20 years, I built, secured and supported distributed systems. <shrug> I do know that this particular mainframe that I'm auditing has problems and I'm attempting to educate myself and provide solutions to my customer rather than being an ignorant black/white auditor (which is a common failing in my experience). That's why I'm here asking this question.

I'd be happy to support my claims of how passwords work on the mainframe with references to the RedBooks that I have read. I have not been able to find any solution to this problem of DES other than using LDAP which is smart from the respect that password storage on LDAP servers such as Oracle, Tivoli, AD (yes, you can use Active Directory as an LDAP authentication server), etc store the passwords securely.

So, I take it that none of the folks here have seen a custom exit? Does everyone use built in RACF/ACF2/TopSecret settings or the DES functions?

Here's a link to a password cracker: http://2000clicks.com/links/Computers/I ... racker.htm and an excellent presentation on how to break into mainframe systems: http://www.stuhenderson.com/XBRKZTXT.PDF

Thanks!

Hello and welcome to the forum,

You might consider asking IBM directly by opening a support issue with them.

They would surely have be best information about available alternatives as they should have been asked this many times.

Thanks very much. I'm certain that's going to be the ultimate direction. IBM is always willing to sell you an answer.

It's tough for auditors as we can't open calls without support contracts, so, I'll have to leave it to the customer.

Thanks!

I suspect that getting the "what is available" info might be free. Getting software might have a cost, but lots of things are downloadable free anymore via the documentation and a series of publications called the Redbooks.

Do you have your own e-mail for that customer organization? If you can find the "site id" you can possibly subscribe to support as yourself, using the company e-address.

Good luck,

d

The issue is, the userIDs follow a standard and DES has a very weak keyspace, therefore password crackers like John the Ripper have an easy time of discovering the password.

How this could be true is very problematic. There are password crackers for z/OS but they require either read access to the RACF data base or APF authorization. If the site prevents both of these activities, then your "easy time" is actually completely impossible. And your example, John the Ripper, does not even run on z/OS so it is a very poor example.

I think you are an auditor looking for a finding -- whether or not the finding has any basis in reality does not really matter -- just that you can report a finding. Security documents, such as http://www.atsec.com/downloads/white-papers/PCI_Compliance_for_LCS.pdf that talk about large computer system compliance with PCI spend no time on this issue, but rather focus on the various areas in which RACF must be used to secure items.

It is possible to write your own ICHDEX01 and ICHDEX11 exits for RACF to replace DES. However, I would expect such an approach to require substantially more verification that this approach does not open up access more than the default RACF algorithms.