Small clarification: The usage of password phrases instead of passwords does not increase the complexity of a brute-force attack against the encrypted hashes, in case the RACF DB gets compromised (flawed / insecure DES implementation). The time required for recovering a 16-byte password phrase is two times the time required for an eight-byte password, for a 24-byte phrase three times, etc. (the required time does not increase exponentially, as expected). The same tech used for recovering passwords can also crack password phrases. There are also collisions, meaning that, in specific cases, in addition to the configured phrase, there will be another two or three distinct ones that also work to authenticate the user (hmm…). The usage of password phrases is of course strongly recommended, but not for saving the day in case of a RACF DB compromise.
Costin ________________________________ From: Walt Farrell <[email protected]> To: [email protected] Sent: Saturday, 17 August 2013, 19:54 Subject: Re: RACF Database protection On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson <[email protected]> wrote: >This exposure has been known--and discussed publicly--for several years. >It is NOT true that 'passwords are not stored'. If they weren't 'stored' >at all, then how could RACF validate the password you supply? They are in >fact stored in encrypted form. The encryption method itself is not a state >secret. It can be simulated. Sorry, Skip, but that's wrong. The passwords are, in fact, not stored at all. (There is one exception, the "password enveloping" function, but that's a different discussion than this one.) RACF encrypts the user ID using the password as the key, and stores the encrypted user ID. The password itself is not saved, in any form. > >The brute force method alluded to here starts with a copy of a RACF data >base. Then generated character strings are fed into an encryption program >until the encrypted form of some random string matches what's found in the >data base for a given userid. Voila. The password has been hacked. No, it's not the "encrypted form of some random string", it's the encrypted form of the user ID, when using some random string as the encryption key. > >Once upon a time, it would have taken so long to perform this string match >that passwords would likely have changed in the meantime. Nowadays >computers all the way down to smart phones have gotten faster while the >encryption algorithms have remained the same. There is to my knowledge no >canonical defense for this hacking method. Best you can do is to prevent >the data base from being copied in the first place. Where possible, you can switch to the use of password phrases rather than passwords. You're right that the brute fore attacks are increasingly simple for mere 8-byte passwords, but password phrases give you longer values (minimum 14 by default, though you can decrease that to 9 with an exit) that will be harder. And with commonly available technology it's perhaps impossible today if you have only a slightly longer string. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
