Code to verify LOGON password

[Sam Golob]

Dear Folks,

    I am just trying to get a very old program to work.  It is so old, 
that it mucks with the TSB password field, and I don't want to deal with 
that.  I don't care to reveal the password anywhere.  I just want the 
user to enter a password, and the security system should say "GO" or 
"NOGO".  That's all.


    Thanks for all your replies.  Be well and safe.

Sincerely,    Sam


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Code to verify LOGON password

[Frank Swarbrick]

RACF Support for IBM Multi-Factor Authentication for z/OS (IBM MFA): 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.izsm100/abstract.htm
Abstract for RACF Support for IBM Multi-Factor Authentication for z/OS (IBM 
MFA)
Purpose of this information This information is a collection of all of the 
information that you need to understand and exploit the IBM Multi-Factor 
Authentication for z/OS (IBM MFA). Some of the information also exists 
elsewhere in the z/OS library.
www.ibm.com



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, January 9, 2021 11:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Code to verify LOGON password

On Sat, 9 Jan 2021 00:12:07 -0600, Brian Westerman wrote:
>
>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.
>
Among these, I wonder about MFA.  Does RACF support MFA?

Why is sftp unable to mask the password entry on a 3270 while FTP does
so readily?

I once submitted an SR that tcsetattr() suppresses ECHO on a linemode
terminal but not a 3270.  IBM rejected it.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Code to verify LOGON password

[Paul Gilmartin]

On Sat, 9 Jan 2021 00:12:07 -0600, Brian Westerman wrote:
>
>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. 
> 
Among these, I wonder about MFA.  Does RACF support MFA?

Why is sftp unable to mask the password entry on a 3270 while FTP does
so readily?

I once submitted an SR that tcsetattr() suppresses ECHO on a linemode
terminal but not a 3270.  IBM rejected it.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Obtaining the Entry Point and Offset for an abending program in the SD WA

[esst...@juno.com]

Hi,
.
I have an ESTAE Recovery program that basically does nothing.
.
I'm Trying to add some code to it.
I have been able to externalized the following:
SDWACMPC Completion Code
SDWAEC1  LEFT HALF OF EC PSW
SDWANXT1 TERMINATION ADDRESS 
.
I'm am trying  to locate two fields in the SDWA.
The entry Point address which I believe is in SDWAEPA, and the Offset.
.
When I display SDWAEPA its always Zeroes.
.
The Program runs as a standard Batch Job with Multiple CSECTS and has an RB.
Why do I always get Zeroes in SDWAEPA ?
.
I don't see a field called "Offset" in the SDWA so I suspect that needs to be
calculated, but with out an Entry Point Address (EPA) I cant' calculate it.
.
Can some shed some light on my lack of understanding of this ? 
.

Paul D'Angelo
.
.
.

 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Code to verify LOGON password

[Tom Brennan]

You're right... and I'm sure Skip Robinson can remember the time we both 
were surprised when an internal penetration test revoked a particular 
RACF id simply because those scripts tried multiple passwords and 
failed.  Guess what, it was FTP like your concerns!  The fun part is 
that only about a week before (for an unrelated issue) we had added a 
WTO to an FTP logon exit/hook that spit out the client's IP address.  So 
we tracked down the people doing the test and probably looked pretty 
good to our managers - just don't tell them it was sheer luck.


And with my RACF SPECIAL id, I do remember logging on to say, TSO, and 
getting stuck for no visible reason until somebody noticed the RACF 
console message you mentioned.  Our operators would "never" respond 
without calling us, but yeah, I can see another sysprog working on some 
other issue responding because they were thinking it was their problem. 
But I think that just gives you another try, and it's way too slow for 
brute force.


On 1/9/2021 8:00 AM, Joel C. Ewing wrote:

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 +, Jousma, David
 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  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








--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Code to verify LOGON password

[Joel C. Ewing]

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 +, Jousma, David
>>  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  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

Re: What were the first models to support Dual Address Space?

[Laddie Hanus]

My fist job in the summer of 1982 used a 4341 group 1 that ran MVS/SP 1.3. It 
did have the Console and PC/AUTH address spaces. Been nearly 40 years ago. 
Laddie Hanus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN