I of course defer to Walt. Fervent ignorance is to be eschewed even when it's fired in the right general direction. In this case, password per se is not stored, but 'something is stored' that could be stumbled upon by a deftly written program running at very high speed forever.
Userids are easily discernible. We run standard RACF utilities to determine for example what profiles a userid owns in order to prepare for deleting that userid. So userids don't have to be guessed at. They're visible in the (purloined) data base. One then 'merely' has to affix a random password string, then crunch the zeroes and ones to find a match in the copied data base. Certainly longer strings like password phrases will take longer to match. But hackers have nothing but time. As my pal Leonard Woren once said: If you build a better mousetrap, the world will build a better mouse. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Walt Farrell <walt.farr...@gmail.com> To: IBM-MAIN@LISTSERV.UA.EDU, Date: 08/17/2013 10:54 AM Subject: Re: RACF Database protection Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Sat, 17 Aug 2013 10:30:57 -0700, Skip Robinson <jo.skip.robin...@sce.com> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
