But keep in mind that while revoking a userid after excessive bad password attempts may prevent a password check routine being used to compromise a specific userid, at the same time that feature enables its use for a denial of service attack to disable a specific userid, or worse, to disable many accounts in a short span of time if the wrong party gains access to the interface and either knows or can guess many userids. You still need to further restrict its use in some way. Out of an abundance of caution, when z/OS FTP became available we used an FTP exit to block FTP logon attempts from userids that had no business using FTP (CICS-only userids, started task userid's etc), just to preclude the possible revocation of production userids from the intentional or accidental inappropriate use of an FTP script or FTP application on some corporate workstation.
There used to be a console message reply required before your RACF Admin users could be disabled in this way, but if some operator blindly gave an inappropriate response for your last RACF Admin userid, you would still be SOL. I vaguely recall we had some console automation to preclude that possibility. Joel C Ewing On 1/9/21 1:46 AM, Tom Brennan wrote: > I seem to remember the verify processing bumping up the password fail > count and revoking the id without any additional logic - even > returning codes indicating those issues. But it's probably been 20 > years since I coded such things, and those brain cells have long since > been loaded with other data. I shouldn't have watched so many > Simpsons episodes. > > On 1/8/2021 10:12 PM, Brian Westerman wrote: >> I think if you were just going to take the password and verify that >> it was correct (or not), that shouldn't be a big issue. Although >> there should be some way to keep the user from using it to "guess" >> other people's passwords. Maybe a limit on tries, or a way to inform >> someone that they tried it more than once in a certain period of time. >> >> With some restrictions, I think that just issuing the RACROUT >> request=verify, would be okay. There should probably be some >> mechanism to revoke the ID if there are two many guesses though. >> >> Brian >> >> >> On Fri, 8 Jan 2021 21:02:50 +0000, Jousma, David >> <david.jou...@53.com> wrote: >> >>> Sam, >>> >>> I'm curious as to the usage scenario? This almost sounds like a >>> security problem? So you take a users password input, go ask SAF if >>> correct? Sounds like a man-in-the-middle situation? >>> >>> _____________________________________________________________________________________________________ >>> >>> Dave Jousma >>> AVP | Director, Technology Engineering >>> >>> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand >>> Rapids, MI 49546 >>> 616.653.8429 | fax: 616.653.2717 >>> >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >>> Behalf Of Sam Golob >>> Sent: Friday, January 8, 2021 12:19 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Code to verify LOGON password >>> >>> **CAUTION EXTERNAL EMAIL** >>> >>> **DO NOT open attachments or click on links from unknown senders or >>> unexpected emails** >>> >>> Dear Folks, >>> >>> Does anyone have user-written code for RACF, so that if the >>> user types in a password, the code will verify if it is the user's >>> actual LOGON password? >>> >>> I'd like to see code that does this, for ACF2 and Top Secret as >>> well, but I'm primarily interested in RACF. >>> >>> Thank you very much. All the best of everything to all of you. >>> >>> Sincerely, Sam >>> >>> >>> >>> -- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
