Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
this is no joke - we had an govt-approved audit program that attempted to check for 'user-id as password' by attempting to login as that user with his/her userid as password (and noting where the login was successful) - reasonable - right? - WELL - someone decided to run this program twice in the same day - and of course 100+ folks (who had previously failed on their last logon attempt and temporarily given up or those who subsequently mistyped their passwords) got ACF2 suspended. When asked - the auditors reply was wow - does that knock out users on the mainframe too? we stopped running this on (whatever non-mainframe platforms) months ago . go figure . Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 [EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
snip- I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. ---unsnip- You would be STUNNED at the number of shops that don't think of something that simple. I could have named three large banking-related institutions here in Greater Chicago that never thought of it until I pointed it out to them. (Business-related discussions, when I was still working.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
--snip There is no easy way to counter such a one and done approach - unless you either improve your database's physical security (don't let it get into the wrong hands) or also require the cracker to physically possess something presumably uniquely identifiable. (Like a physical key but usually electronic.) It isn't so much that good guys are getting harder to find as it is that bad guys are getting a little bit sneakier. unsnip Securing the RACF DB and all its backups will go a LONG way toward blocking these bad guys. Amazing how many shops don't take those simple steps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Rick Fochtman wrote: snip- I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. ---unsnip- You would be STUNNED at the number of shops that don't think of something that simple. I could have named three large banking-related institutions here in Greater Chicago that never thought of it until I pointed it out to them. (Business-related discussions, when I was still working.) Let me ask this question - although this is not directly related to RACF - but to any access control system that locks out people upon failed access attempts.. Isn't locking out or revoking someone because of unsuccessful access attempts a wonderful denial of service attack opportunity ? You wait for your good friend in the next cubicle to go on a coffee break.. log him off (it he hasn't already done so) - and attempt to log in with bogus passwords 3 times.. and while you are at it, do the same for some other userids of some highly ranked officers from HIS terminal.. There is going to be some embarrassment for a LOT of people and a lot of time lost.. (your co-worker, the locked out people, the person responsible for security).. I am of course not saying anyone should do that.. But isn't it a potential problem with user name lockouts ? --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
-snip-- Let me ask this question - although this is not directly related to RACF - but to any access control system that locks out people upon failed access attempts.. Isn't locking out or revoking someone because of unsuccessful access attempts a wonderful denial of service attack opportunity ? You wait for your good friend in the next cubicle to go on a coffee break.. log him off (it he hasn't already done so) - and attempt to log in with bogus passwords 3 times.. and while you are at it, do the same for some other userids of some highly ranked officers from HIS terminal.. There is going to be some embarrassment for a LOT of people and a lot of time lost.. (your co-worker, the locked out people, the person responsible for security).. I am of course not saying anyone should do that.. But isn't it a potential problem with user name lockouts ? ---unsnip The scenario you describe is quite possible. In shops where I've worked, getting caught doing something like that would result in a speedy promotion: to the street. And DON'T ASK FOR REFERENCES! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Rick Fochtman wrote: ---unsnip The scenario you describe is quite possible. In shops where I've worked, getting caught doing something like that would result in a speedy promotion: to the street. And DON'T ASK FOR REFERENCES! I know... But we are talking security issues here. Maybe a disgruntled employee who is about to get a pink slip or about the send a resignation letter anyway.. doing those kind of actions could make considerable damage to the company if the timing is right - while someone succeeding into breaking into a critical account by brute force seems to me more unlikely. I am going on the premise that someone caught attempting to circumvent or abuse security measures is at risk *anyway* ! What I am hinting here is that account locking COULD (in certain situations) be a security *risk* rather than a security enhancement to a system - because although brute force cracking of account credentials is possible, abusing a userid lockout is far easier and accessible to implement (it doesn't even require any skill) ! And don't ask me about those 'secure' systems that ask you to change your password every 2 weeks - with passwords that must be at least 32 characters long, with no dictionary words, a mix of upper/lower/digits/special chars - which invariably get written on post-it(tm)s and hidden under the keyboard. Just my .02€ --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
---snip- The scenario you describe is quite possible. In shops where I've worked, getting caught doing something like that would result in a speedy promotion: to the street. And DON'T ASK FOR REFERENCES! I know... But we are talking security issues here. Maybe a disgruntled employee who is about to get a pink slip or about the send a resignation letter anyway.. doing those kind of actions could make considerable damage to the company if the timing is right - while someone succeeding into breaking into a critical account by brute force seems to me more unlikely. I am going on the premise that someone caught attempting to circumvent or abuse security measures is at risk *anyway* ! What I am hinting here is that account locking COULD (in certain situations) be a security *risk* rather than a security enhancement to a system - because although brute force cracking of account credentials is possible, abusing a userid lockout is far easier and accessible to implement (it doesn't even require any skill) ! And don't ask me about those 'secure' systems that ask you to change your password every 2 weeks - with passwords that must be at least 32 characters long, with no dictionary words, a mix of upper/lower/digits/special chars - which invariably get written on post-it(tm)s and hidden under the keyboard. -unsnip-- You're still quite accurate. Here's what I did to avoid an extended outage: (Keep in mind that this was quite some years ago, before additional controls were implemented in RACF vis-a-vis started tasks): 1. I installed an exit which would allow all started tasks to run, whether they supplied valid passwords or not. The Systems Programming staff had complete control of Started Tasks, and any parmlibs that they might use. 2. I installed a Started Task that would RESUME selected userid's, with pre-determined passwords, based on parms provided in a tightly-controlled PARMLIB. 3. Access to the RACF DB, and its backups, was tightly controlled so that a brute-force approach, by unloading the RACF DB, wasn't possible outside the Security Administration staff (Me and one other System Programmer). 4. LOGON and Attempted LOGONs were audited, whether successful or not. A regular report of that information was generated, both for security admin staff and senior management. Information included was, among other items, USERID, number of attempts and TERMID (Thank you, VTAM). 5. If any DOS attempt was made for production userid's, the Operations staff had instructions to Run this Started Task and notify the ENTIRE security admin staff ASAP. We could then run some RYO reports to try and pinpoint the issue and/or offender. IIRC, there's been a modification to RACF such that a started task will never be denied LOGON access; what happens after that depends on the various profiles in the RACF DB. We had a job scheduling package in place and we used the propogation features for USERID and password, so NO production job contained either form of information. Another exit, for TSO SUBMIT, disallowed any USERID and/or password information to be submitted via TSO SUBMIT commands. A very few people were allowed to supply USERID information, via the SURROGATE mechanism of RACF. NOBODY was given SURROGATE authority for Started Tasks; even the security folks didn't have it. And STC Production passwords were unknown. The job scheduler had SURROGATE access for the various production ID's, so providing a password was not needed. Sooner or later, you'll have to invest a certain amount of trust in a selected, and trusted, few employees. If you can keep that to a minimum, you can minimize the risks of an extended outage because of security abuse; you just have to decide who you trust. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
--snip-- Well.. I know (or at least it, so it appears - since I don't *KNOW* you) you are indeed a thoughtful security officer.. (And.. err.. started tasks bypassing authentication is definitely a solution - yet - doesn't it give people with access to the console an awful lot of power ? (just a question.. I'm not a z/OS guy ! maybe I'm getting this all wrong !). unsnip You can definitely control what can be run as a started task. You need to understand JESS2 JCL and control statements but controlling STC access is definitely possible. And I tried very hard to be a good, thoughtful security officer. I sometimes P***ed off my management because I refused to reveal certain passwords, etc. to management or even to security auditors. snip--- The message I am sending is that a 'three strikes and you're out' solution is not a panacea. I wasn't sending the message to you - but rather - to *everyone* out there who may be confronted with the evil 'know it all' auditor/consultant who is going to *instruct* people to implement these sort of measures indiscriminately (because that's what is on his checklist !)... And maybe to those who hadn't thought of some of implication of such a policy (if it isn't implemented correctly). ---unsnip-- Nothing is a complete solution in this area. But auditors like to see some form of reasonable limitation in this area. Negative implications don't interest most auditors; they have, in most cases, their own pre-conceived ideas. And unfortunately, management is more likely to listen to them than you, because they paid some (outrageous) fee for the auditor's opinion. --snip Actually a 100 strikes and you're out (or some quite large number) may be a possible solution : it avoids brute force attack through some TN3270 API - yet - someone doing this will be easily detectable - AND it avoids the CEO with a bad hair day to be locked out - and starting firing people by the dozen (because eveyone knows the CEO will *have* a bad hair day[1] on the critical day). --unsnip- See above comment. If the CEO gets hit, that's tough. If he's not security conscious, then make him set the standards, in writing. He can live (or die) by his own pronouncements. Wait'll the auditor sees it, then watch the fertilizer hit the Westinghouse. ---snip Then again, a script kiddie may be able to lock out people that way.. (but it does lower the risk).. unsnip The more chances you give that script kiddie, the better his chances of success. 'nuff said?? ---snip--- And about the password aging problem and complexity.. My (personal) recommendation is (mind it, I am NOT a security officer.. just an aging sysprog) : allow passwords to remain unchanged for a long period of time - yet - force somewhat complicated passwords : This way : people won't have to write them down, however, they are hard to crack (through bruteforce attacks on hashes) and - furthermore - once they are accustomed to their passwords, they will type them fast at the keyboard (mitigating the 'over the shoulder' attack). My usual password isn't very long - 8 chars.. but I can type it in a matter of ~500 ms. ---unsnip Password aging and complexity can be good things, provided they aren't carried too far. Because of business functions, our users had to logon at least monthly, on the first business day of the month. So we gave them 36 days. But if a password had leading or trailing digits, we required at least two digits and we didn't allow a password to be a anagram (scramble) of the user id. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 10:06:33 -0500, Bass, Walter W [EMAIL PROTECTED] wrote: I recall the password encryption algorithm for IDMS back in the late 80's worked by repeatedly multiplying and then discarding the upper byte of the result. We actually duplicated this logic in COBOL so that we could hash user entered passwords and compare them to the stored values in the data dictionary. This algorithm was considered irreversible because there was no way of knowing the value of the bits that got discarded at each repetition and a single hash could not decrypt to one unique password. If I wanted to crack this, I would start with: http://en.wikipedia.org/wiki/Linear_congruence_theorem -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Wed, 21 May 2008 12:19:16 -0500, Chase, John [EMAIL PROTECTED] wrote: You could also have said (truthfully) that RACF doesn't store passwords. As documented in the SecAdmin Guide, RACF uses the tendered password as a key to one-way encrypt the userID, and stores the encrypted userID. Thus, it is (remotely) possible that a given userID could have more than one valid password at a given time. I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. DC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
I recall the password encryption algorithm for IDMS back in the late 80's worked by repeatedly multiplying and then discarding the upper byte of the result. We actually duplicated this logic in COBOL so that we could hash user entered passwords and compare them to the stored values in the data dictionary. This algorithm was considered irreversible because there was no way of knowing the value of the bits that got discarded at each repetition and a single hash could not decrypt to one unique password. However, since the original encryption algorithm was known, I believe that the passwords could have been broken by a brute force decryption program that simply substituted all 256 possible values in place of the discarded byte and create a list of all possible passwords that could have encrypted to the current hash. Once that list of possibles is created, you just look for the one that consists entirely of EBCDIC characters and you have your password. Bill Bass United Health Care Greenville SC -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Cartwright Sent: Thursday, May 22, 2008 10:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts) On Wed, 21 May 2008 12:19:16 -0500, Chase, John [EMAIL PROTECTED] wrote: You could also have said (truthfully) that RACF doesn't store passwords. As documented in the SecAdmin Guide, RACF uses the tendered password as a key to one-way encrypt the userID, and stores the encrypted userID. Thus, it is (remotely) possible that a given userID could have more than one valid password at a given time. I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. DC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
--snip--- I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. -unsnip-- I'd sure like to see his mechanism. Security is one of my hot buttons, having been a RACF administrator for many years. My RACF database files were also RACF protected. When I was asked for an unloaded copy, I had a special little program, using UPDAT I/O, that set all password fields toX'00 values so nobody could even try to decypher passwords. At least, not with any hope of success. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 09:17:34 -0500, Dave Cartwright [EMAIL PROTECTED] wrote: On Wed, 21 May 2008 12:19:16 -0500, Chase, John [EMAIL PROTECTED] wrote: You could also have said (truthfully) that RACF doesn't store passwords. As documented in the SecAdmin Guide, RACF uses the tendered password as a key to one-way encrypt the userID, and stores the encrypted userID. Thus, it is (remotely) possible that a given userID could have more than one valid password at a given time. I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. No, it's not an urban myth. Properly configured (to use DES (the default), rather than masking), RACF does not store a user's password on the DB. It encrypts the user ID using a slight modification of the password, and saves the encrypted result. All you can do, assuming you can read the DB to extract the encrypted value, is a brute force attack where you propose a password, encrypt the user ID, and see if it matches. That's a significant amount of work, though of course: (a) machines are getting faster, and the work can perhaps be split across many machines. (b) overly restrictive password rules can reduce the amount of work. Note, though, that this kind of attack requires either the ability to run an APF-authorized program on the system, or physical access to a copy of the database, in order to retrieve the encrypted value. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Heck, Nigel Pentland has two utilities that look for weak passwords (DOS- based) that I'ved used for quite some time to ensure a client is using strong passwords - CRACF and WEAKWORD. One just checks the USERID or DFLTGRP name, and the other uses a dictionary list. WEAKWORD (the dictionary list one) doesn't display the password. So yes, the passwords are recoverable - after a fashion. On Thu, 22 May 2008 11:18:13 -0500, Rick Fochtman [EMAIL PROTECTED] wrote: --snip--- I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. -unsnip-- I'd sure like to see his mechanism. Security is one of my hot buttons, having been a RACF administrator for many years. My RACF database files were also RACF protected. When I was asked for an unloaded copy, I had a special little program, using UPDAT I/O, that set all password fields toX'00 values so nobody could even try to decypher passwords. At least, not with any hope of success. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 11:46:18 -0500, Walt Farrell [EMAIL PROTECTED] wrote: On Thu, 22 May 2008 09:17:34 -0500, Dave Cartwright [EMAIL PROTECTED] wrote: ...snipped... I'm now wondering if this is an urban myth. At the GSE LSWG meeting last Tuesday Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. No, it's not an urban myth. Properly configured (to use DES (the default), rather than masking), RACF does not store a user's password on the DB. It encrypts the user ID using a slight modification of the password, and saves the encrypted result. All you can do, assuming you can read the DB to extract the encrypted value, is a brute force attack where you propose a password, encrypt the user ID, and see if it matches. That's a significant amount of work, though of course: (a) machines are getting faster, and the work can perhaps be split across many machines. (b) overly restrictive password rules can reduce the amount of work. Note, though, that this kind of attack requires either the ability to run an APF-authorized program on the system, or physical access to a copy of the database, in order to retrieve the encrypted value. Ray assures me that he did not say that he can recover passwords. He did say that when he finds he has READ access to the RACf database, that he retrieves the encrypted data and breaks the encryption. That specifically means a brute force password guessing attack such as I described above. His purpose in mentioning that was to make sure that people understand that giving users READ to the RACF database is not a safe thing to do. We have had discussions with z/OS security administrators who have felt that since the password itself is not saved, that there's no reason to prohibit reading the database, and Ray was pointing out the flaw in that thinking. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. Eric Doc Farmer [EMAIL PROTECTED] wrote: Heck, Nigel Pentland has two utilities that look for weak passwords (DOS- based) that I'ved used for quite some time to ensure a client is using strong passwords - CRACF and WEAKWORD. One just checks the USERID or DFLTGRP name, and the other uses a dictionary list. WEAKWORD (the dictionary list one) doesn't display the password. So yes, the passwords are recoverable - after a fashion. -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 14:23:53 -0500, Eric Bielefeld wrote: I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. If you have been successful in obtaining and cracking the RACF database (or a database copy) then you will only need 1 try -- it ought to be successful. There is no easy way to counter such a one and done approach - unless you either improve your database's physical security (don't let it get into the wrong hands) or also require the cracker to physically possess something presumably uniquely identifiable. (Like a physical key but usually electronic.) It isn't so much that good guys are getting harder to find as it is that bad guys are getting a little bit sneakier. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
Ray Evans the IBM UK Penetration Testing Manager claimed several times to be able to recover passwords from a copy of the RACF database. I have a recording of the presentation. I hope this doesn't get him into trouble as it was a very good presentation. Look after your RACF D/B - security begins at home. This has been discussed many times on RACF-L. If you can get at a copy of a RACF D/B, you can do a 'brute force' attack on the passwords, especially if you know the encryption algorithm, which is not a secret. Hence, IBM (and most security experts recommend protecting both the D/B and all copies. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. Brute force against a copy of the RACF D/B. Solution: protect the D/B and all copies. As for the 3 strikes rule, I agree. It's deja vu for the very first time. This discussion thread has been done over on the RACF-L. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
