It's not the PTF that creates the exposure; it's the autorevocation policy, with or without the PTF.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Peter Vander Woude <[email protected]> Sent: Thursday, January 23, 2020 9:31 AM To: [email protected] Subject: Re: IBM AOAR O44855 The apar is meant to deal with those types of hacks, where someone has a list of userids and then just try to logon to TSO by connecting and attempting to logon to TSO. Without the apar/parm, the normal logon screen shows the person IF the userid actually has a TSO profile.d When the correct parm is in the IKJTSO00 parmlib member, they just get a prompt for the password. There is no notification at that point that the user does, or does not, have TSO access. Even the response does not tell the hacker that information. While I agree that it could be a vein for a ddos of getting the users id revoked, the premise is valid to prevent the identification of someone with TSO access is very valid. <<<< Subject: Re: IBM AOAR O44855 From: Seymour J Metz <[email protected]> Reply-To: IBM Mainframe Discussion List <[email protected]> Date: Tue, 21 Jan 2020 16:31:42 +0000 That opens the way to a denial of service attack; someone can write a script to cause revocation of a long list of userids. -- Shmuel (Seymour J.) Metz ---------------------------------------------------------------------- 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
