TL;DR ->Earlier this year IBM updated (and made backwards compatible to z/os v1r12) their RACF password hashing/encryption technology – and it’s awesome. The APAR OA43999 has been out for months and, after you research and test it, you should apply it then migrate your users to the stronger algorithm as soon as you can. This increases the complexity of brute forcing RACF passwords from hours/days to months/years! Want more info/background? Read on….
RACF, IBM’s ESM (external security manager) uses an outdated and insecure password hashing/encryption algorithm. Their implementation of DES to encrypt and protect the user’s password is trivially easy to compromise with simple hardware.
The [old] rules and implementation of passwords on the mainframe have been the topic of much discussion and teeth gnashing. While RACF supported passphrases and mixedcase passwords (as opposed to the maximum 8 character, case insensitive previous default) back in 2005; the TSO component did not until a few years later. And, even then, companies were slow to adopt because the change was difficult to reverse and in-house/3rd party developed programs may have relied on the original restrictions.
The RACF DES algorithm, implementation, and location of hashes in the RACF database on the system are well known and common tools (like John the Ripper ) support converting and cracking them offline with ease. OclHashcat also has support for brute forcing RACF DES passwords; thus adding the advantages of GPU brute forcing to the mix.
Enter APAR OA43999. Here (IBM’s original statement of direction for RACF) and here: Taking the sword out of password <- a presentation of what comes with the update. There are a great deal of cool features in this APAR. The main one I want to focus on is the KDFAES password hashing and profile encryption algorithm.
A KDF (Key Derivation Function) is a way to take a password, bolt on some random data (to prevent the use of rainbow tables), hash it with a common algorithm (here SHA256) 1000s of times to ultimately generate a byte sequence of a predetermined length, which can then be used as the key for a solid symmetric crypto algrithm (in this APAR, they are using AES) which then encrypts the users profile.
IBM chose (from what I gather in the APAR doco) to implement PBKDF2-SHA256. PBKDF2 can be tailored to both use a tremendous number of iterations of hashing the password as well as forced to use a large amount of main memory to do so. Arbitrarily using large amounts of memory can help slow down offline brute-force attacks.
How does this help prevent password brute forcing? Password cracking is a trivially easy process to parallelize. It works like this: potential password plain texts are run through the same DES-based algorithm used to encrypt the passwords on the mainframe, then compared to the offline RACF database. The PBKDF2 algorithm slows down the brute forcing process exponentially.
It’s not at all uncommon to have a machine, relatively inexpensive to build with off-the-shelf (think Amazon, Newegg, Bestbuy) parts and yield billions of guesses per second (for something like MD5) or 100s of millions for RACF/DES.
Device #1: GeForce GTX 550 Ti, 1023MB, 1800Mhz, 4MCU Hashtype: MD5 Workload: 1024 loops, 256 accel Speed.GPU.#1.: 1128.4 MH/s **************************************************** Device #1: GeForce GTX 550 Ti, 1023MB, 1800Mhz, 4MCU Hashtype: RACF Workload: 1024 loops, 256 accel Speed.GPU.#1.: 131.0 MH/s **************************************************** Device #1: GeForce GTX 550 Ti, 1023MB, 1800Mhz, 4MCU Hashtype: (PBKDF2-SHA256) Workload: 1024 loops, 8 accel Speed.GPU.#1.: 2856 H/s
However, the hashing function most similar to what IBM is describing would be at the bottom of the above test (PBKDF2-SH256) – notice it yields a paltry ~2.8k guesses per second compared to RACF/DES’s 131million/second. Those results were from a very modest rig that I own which has 1 smallish GPU. Better results are possible with slightly larger hardware, but the rates will still be an order of magnitude smaller than what’s possible for DES.
Net is – this is a great move. If someone was able to get a copy of your RACF database prior to this APAR, with the traditional RACF DES (middle test above about 100Mh/s on my box) 8 char maximum, case-insensitive alpha, digits, and only 3 special chars ($#@) – they could run the entire keyspace in a about 10 days max (much much faster on a box with bigger/faster GPUs).
Session.Name...: cudaHashcat Status.........: Running Input.Mode.....: Mask (?1?1?1?1?1?1?1?1)  Hash.Target....: File (./racf.text) Hash.Type......: RACF Time.Started...: Sun Oct 11 23:49:41 2015 (5 secs) Time.Estimated.: Fri Oct 23 15:11:09 2015 (11 days, 15 hours) Speed.GPU.#1...: 122.4 MH/s Recovered......: 17/40 (42.50%) Digests, 17/40 (42.50%) Salts Progress.......: 692060160/123096212991063 (0.00%) Rejected.......: 0/692060160 (0.00%) Restore.Point..: 0/90224199 (0.00%) HWMon.GPU.#1...: -1% Util, 46c Temp, 41% Fan
After the PTF (and especially if you broaden your keyspace to passphrase size or even mixed chars with the additional symbols) we’re now talking years (many many years) to crack them. The one caveat is that assumes people do not use passwords that are easy to guess (like dictionary words) or compute (such as common words with an 01 added to the end).
The APAR provides for backwards compatibility with DES to allow a deliberate roll-out (existing users can use DES until they change their passwords). A good deal all around.
Some fun light reading:
[EDIT 10/13 – thank you to @solardiz for pointing out my descrypt comparison was wrong – updated to reflect RACF (which is brute forced much faster than descrypt)