Could well be. I vaguely remember something about Triple DES somewhere. But my mind is a bit "loose" right now on meds.
John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert S. Hansel (RSH) > Sent: Monday, November 29, 2010 5:25 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: A New Threat for password hacking > > John, > > I believe RACF only uses single DES, not Triple DES. > > Regards, Bob > > Robert S. Hansel > Lead RACF Specialist > RSH Consulting, Inc. > 617-969-8211 > www.linkedin.com/in/roberthansel > www.rshconsulting.com > > --------------------------------------------------------------------- > 2011 RACF Training > > Intro & Basic Admin - WebEx - JAN 24-28 > > Securing z/OS Unix - WebEx - FEB 8-10 > > Audit for Results - Boston - APR 12-14 > > Intro & Basic Admin - Boston - MAY 10-12 > Visit our website for registration & details > --------------------------------------------------------------------- > > -----Original Message----- > Date: Sun, 28 Nov 2010 19:37:37 -0600 > From: John McKown <joa...@swbell.net> > Subject: Re: A New Threat for password hacking > > RACF password encryption is explained here: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ich > za290/3.3.1 > > It uses Triple DES where the password is a key to encrypt the userid, > which encrypted value is then stored in the DB. So two different users > with the same password would have two different encrypted values. It > also states it is a "one way" encryption. There is no way to > "back out". > To crack a password would require having the unencrypted RACF id, the > encrypted stored value, and the exact algorithm. Now, I'm not a > cryptographer, but I don't think you can use that information to > recreate a valid password easily. So you're more likely to try a brute > force dictionary attack. Again, using an NSA quality supercomputer, I > have no idea how long this would take. I think I'd just play the lotto > and win sooner. But that is my ignorance speaking. > > On Sun, 2010-11-28 at 19:15 -0600, Paul Gilmartin wrote: > > On Sun, 28 Nov 2010 15:56:36 -0600, Russell Witt wrote: > > > > >Easy to say "do not share your RACF db"; harder in > reality. Most sites > > >believe they are safe because their RACF db is security > protected and the > > >dasd is not shared. And then completely forget that > backups (to physical > or > > >virtual tape) contain the exact same information. And > quite often the DSN > > >used for the backup tapes is some type of dasd-manager > HLQ, since it was > > >most likely a full-volume backup that happen'ed to contain > the RACF db. > And > > >even if the HLQ for the full-volume backups is > read-protected; it is > still > > >far easier to hack a tape dataset. Often, tape libraries > (physical and > > >virtual) are shared with less-secure test machines and > quite often even > with > > >non z/OS systems. Granted, you will need the physical > layout of the RACF > db; > > >but not the entire layout. Just enough to identify where > the passphrases > are > > >maintained. > > > > > Aren't the passwords encrypted? But how strong is the encryption? > > > > It would be peculiarly pointless to store fewer bits of the > encrypted > > password than are used in the encrypting key. > > > > -- gil > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET > IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- > John McKown > Maranatha! <>< > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
