Re: RACF, external password management

[Robert S. Hansel]

Hi Linda,

How do you define "common password"?

Regards, Bob

Robert S. Hansel   2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Wed, 28 Feb 2024 15:35:54 -0600
From:Linda Hagedorn 
Subject: RACF, external password management

My company wants an external password manager to substitute for RACF.  
I need to know if anyone has experience with this, or common password matching 
in RACF.  

Background
Regulations NYDFS require preventing common passwords to be used. 
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.  
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible. 

Any input is appreciated.  Thanks!  Linda  

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

Re: RACF, external password management

[kekronbekron]

Hi Bob,

If it is what I am thinking... I didn't think this day would come.
There are hashes of known, breached passwords generally collected.
Here's the most prominent one - https://haveibeenpwned.com/Passwords

There are blog posts on the same site explaining what it is, how to use that 
collection, etc.
Would be fun indeed if the collection can be brought to zOS and RACF/ACF2 
adapted to look up a new pw in it, before using/setting it.


On Thursday, February 29th, 2024 at 17:13, Robert S. Hansel 
 wrote:

> Hi Linda,
> 
> How do you define "common password"?
> 
> Regards, Bob
> 
> Robert S. Hansel 2024 IBM Champion
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> www.rshconsulting.com
> 
> -Original Message-
> Date: Wed, 28 Feb 2024 15:35:54 -0600
> From: Linda Hagedorn linda.haged...@gmail.com
> 
> Subject: RACF, external password management
> 
> My company wants an external password manager to substitute for RACF.
> I need to know if anyone has experience with this, or common password 
> matching in RACF.
> 
> Background
> Regulations NYDFS require preventing common passwords to be used.
> Vendor tools (Courion, CyberArk, etc.) have a corpus to match password 
> changes to prevent the use of common passwords.
> RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
> Session manager, etc., so trying to block password changing through RACF and 
> forcing everyone through one of these 3rd party tools may be near impossible.
> 
> Any input is appreciated. Thanks! Linda
> 
> --
> 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: RACF, external password management

[Linda Hagedorn]

This is exactly where I'm going.  

I think IBM should, if they haven't already, find a way to register the 
frequently found passwords and make an option to scan the PW in RACF.  
There may be a liability, but certainly a disclaimer can be included in the 
license.  

If this already exists, a referral to the manuals would be appreciated.  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF, external password management

[Linda Hagedorn]

Commonly used passwords and those found in breaches (dark web for example). 

P@$$w0rd, etc.

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

Re: RACF, external password management

[Linda Hagedorn]

This is very promising.  Do you know where I can read more about ZMFA?  

I'm interested in knowing how to configure the external source, and how the 
token is passed back to RACF, and how long the token lasts.  

For example, if systems programmers are working a problem, we wouldn't want the 
token to expire in 3 hrs.  
Or does the token last for the duration of the session?  
If tso/ispf times out (sysprog is doing research or answering mgmt questions), 
will they have to generate a new token?

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

Re: RACF, external password management

[Linda Hagedorn]

Do you know if there's any development to ingest the list of passwords known to 
be involved in breaches, and match RACF password changes against them?

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

Re: RACF, external password management

[Linda Hagedorn]

In the process you describe, could I still while logged into tso/ispf change my 
password in RACF, bypassing the AD routine?  

// JOB (ACCT INFO),'PGMR INFO',
// CLASS=??,MSGCLASS=??,NOTIFY=userid,
// USER=userid,PASSWORD=(OLDPASS,NEWPASS)
//IEBFR14  EXEC  PGM=IEFBR14

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

Re: RACF, external password management

[Steve Thompson]

I think the exit point(s) mentioned by others is(are) where you 
would check the clear text against those common passwords, and 
reject that password change at that point.


Specifically to your question "any development to ingest": Unless 
you can find a vendor to provide you with such, your "shop" may 
have to do this, updating the table (or disk file) that contains 
the proscribed passwords.


And another thing you have to think about: Can you set rules that 
could keep such passwords from being tried?


Let's say they all have in common the use of $$, or ## or some 
such, so you would restrict any character from being repeated. 
But at the same time, suppose this is only seen in passwords of 
less than 10 characters...


[I've been exposed to many different systems with different rules].

Not that you would want to go this far, but you may need to go to 
2FA, depending on how secure you have to be (that could be a pain 
in your submit a job to change pswd


Another question: How do you make up your user-IDs? Now looking 
at the common passwords, can one know what user id was 
associated? This goes to the exposure you have to these common 
passwords.


   How many attempts to user-id revoked?
   How does one get their id restored?

   Suppose you are logged on, and a dictionary attack is done
   and your ID is now flagged as revoked. How do you get out of
   this?

Many things to think about. But mostly what is your exposure to 
an attack?


What if I wanted to shut down your biz? If I know how all of your 
user-ids are constructed, and I can get access to your system, 
somehow, and do dictionary attacks to cause all IDs to get 
revoked  It has been done.


Steve Thompson


On 2/29/2024 12:44 PM, Linda Hagedorn wrote:

Do you know if there's any development to ingest the list of passwords known to 
be involved in breaches, and match RACF password changes against them?

--
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: RACF, external password management

[Howard Rifkind]

Sorry no; was this problem on the main frame?  

Sent from my iPhone

> On Feb 29, 2024, at 13:00, Linda Hagedorn 
> <05cf4637de00-dmarc-requ...@listserv.ua.edu> wrote:
> 
> In the process you describe, could I still while logged into tso/ispf change 
> my password in RACF, bypassing the AD routine?  
> 
> // JOB (ACCT INFO),'PGMR INFO',
> // CLASS=??,MSGCLASS=??,NOTIFY=userid,
> // USER=userid,PASSWORD=(OLDPASS,NEWPASS)
> //IEBFR14  EXEC  PGM=IEFBR14  
> 
> --
> 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: RACF, external password management

[Radoslaw Skorupka]

W dniu 28.02.2024 o 22:35, Linda Hagedorn pisze:

My company wants an external password manager to substitute for RACF.
I need to know if anyone has experience with this, or common password matching 
in RACF.

Background
Regulations NYDFS require preventing common passwords to be used.
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible.

Any input is appreciated.  Thanks!  Linda


My humble input: go MFA.
Explanation
You can easily forbid dictionary passwords by ALPHANUM - a mix of 
alphabetics and numbers.
So, no sophisticated English (or Polish) word will be accepted. However 
PASSWRD1 will be.

You can enforce use of uppercase and lowercase. Passwrd1 will be accepted.
You can turn off old passwords and enforce pass phrases. "My Password01" 
will be accepted. Yes, with the space.
You can create and maintain your own black list of forbidden passwords - 
now neither of the above will not be accepted. However this is a little 
bit more complex - you need to code and maintain password (passphrase) 
exit. It can be REXX code.


Finally you still have a problem - your employee used his car plate 
number, for example LDB-9091. Looks fine, but ethical hacker will try 
this id. Mother's name? Wife's car plate number? No. You are not able to 
collect that information, but ethical hacker would try it!


The solution is MFA. Yes, the password is still important, however the 
hacker has no token.

Advantage: JOHN will no longer be able to share his password with MARY.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: RACF, external password management

[Linda Hagedorn]

The regulations are from NY state, NYDFS.  
https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf

 500.7 Access privileges and management.

 500.7(c) Each class A company shall monitor privileged access activity and 
shall implement:
 (1) a privileged access management solution; and
 (2) an automated method of blocking commonly used passwords for all 
accounts on
 information systems owned or controlled by the class A company and 
wherever feasible
 for all other accounts.  

To automatically block commonly used passwords, a corpus is necessary.  For 
example, Cybernews Investigation team was able to collect 15m passwords.*  If 
they can do it, software vendors will see the opportunity here.   

It's one option to force all RACF password changes through a single point.  
However, there's a lot of ways to reach the password change process in MVS, and 
writing blocks for all of them isn't reasonable.  
 
The ZMFA holds promise, if I can find a software company that has 
bought/collected the same 15m passwords that Cybernews did.  I can route all 
RACF password changes to the  software company for 
validation.  


*https://cybernews.com/best-password-managers/most-common-passwords/

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

Re: RACF, external password management

[roscoe5]

I like it. And there are more than one potential software vendors reading your 
request on this site. ;-)

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Thu, Feb 29, 2024 at 3:53 PM, Linda Hagedorn 
<[05cf4637de00-dmarc-requ...@listserv.ua.edu](mailto:On Thu, Feb 29, 2024 
at 3:53 PM, Linda Hagedorn < wrote:

> The regulations are from NY state, NYDFS.
> https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf
>
> 500.7 Access privileges and management.
>
> 500.7(c) Each class A company shall monitor privileged access activity and 
> shall implement:
> (1) a privileged access management solution; and
> (2) an automated method of blocking commonly used passwords for all accounts 
> on
> information systems owned or controlled by the class A company and wherever 
> feasible
> for all other accounts.
>
> To automatically block commonly used passwords, a corpus is necessary. For 
> example, Cybernews Investigation team was able to collect 15m passwords.* If 
> they can do it, software vendors will see the opportunity here.
>
> It's one option to force all RACF password changes through a single point. 
> However, there's a lot of ways to reach the password change process in MVS, 
> and writing blocks for all of them isn't reasonable.
>
> The ZMFA holds promise, if I can find a software company that has 
> bought/collected the same 15m passwords that Cybernews did. I can route all 
> RACF password changes to the  software company for 
> validation.
>
> *https://cybernews.com/best-password-managers/most-common-passwords/
>
> --
> 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: COBOL 6 and On Size Error at ARCH(12)

[Attila Fogarasi]

A couple of ideas ... if you can use ARCH(13) and Cobol v6.3 then it may
handle the overflow bits differently.  As for doc on what ON SIZE ERROR
should do, it does specify " If the ON SIZE ERROR phrase is specified and a
size error condition occurs, the value of the resultant identifier affected
by the size error is not altered; that is, the error results are not placed
in the receiving identifier." ... possibly what you see violates that
specification (in the Cobol v6 manual) by altering the resultant
identifier.

On Fri, Feb 23, 2024 at 3:05 AM Schmitt, Michael 
wrote:

> I'm in discussion with IBM on a issue with the COBOL 6 compiler at ARCH
> level 12. I think it is generating incorrect code, Development says "but
> generating correct code would make it less faster!". I want to see what you
> think.
>
> The issue is related to overflows, such as a packed-decimal overflow.
> COBOL /ignores/ overflows, unless you code ON SIZE ERROR, which catches
> them. By "ignores" I mean it just lets the field overflow.
>
> But at the machine level, a doing an AP instruction that causes an
> overflow (or any other instruction) will case a program check, depending on
> the setting of the decimal-overflow mask in the PSW. Therefore Language
> Environments sets the bit off to ignore overflows.
>
> BUT, C semantics are that it needs to actually raise an exception or
> something when there is an overflow. When a COBOL program calls a C
> program, LE sets the overflow bit on so now overflows actually get a
> program check (which may be caught by an ESPIE). Upon return from C, LE
> doesn't set the bit back to off. Instead, LE catches the overflows and
> ignores them.
>
> Note that this isn't just an application COBOL program calling an
> application C program. It also include use of services written in C. For
> example, the mere inclusion of XML PARSE or XML GENERATE in a COBOL program
> will drive LE to initialize the C interface, setting the overflow mask on.
>
> That's how it is supposed to work.
>
> But, sometimes after LE changes the bit to on, LE loses its conditional
> handlers. The result is that a COBOL program *will* get a program check for
> an overflow. How can this happen, you ask? One way involves reusable
> run-time systems established by CEEPIPI. (I have an Idea open about this
> issue.)
>
> The work around for that problem is that if you code ON SIZE ERROR, COBOL
> will catch the overflow. I say this means "catch the overflow WITHOUT A
> PROGRAM CHECK", Development says "show us the doco that says it must catch
> it!".
>
> Anyway, at arch levels 11 lower, a COBOL program will not get a program
> check when there is an overflow in a statement that has ON SIZE ERROR. The
> *way* it prevents this is it generates code that performs the operation
> using fields that are large enough that no overflow can occur, then it
> tests to see if it overflowed into the larger field. For example, if you
> are adding a 1 digit field to a 3 digit field, then the COBOL compiler does
> the add using a 4 digit field, and then checks if the high digit is not 0.
> If it is, then it goes into the ON SIZE ERROR logic. So, no program check,
> because at a machine level there was no overflow.
>
> The difference with arch level 12 is that the IBM Enterprise COBOL for
> z/OS v6 compiler will exploit the vector decimal instructions. These
> instructions have PSW bits that control whether they will fire a
> program-check for overflows.
>
> And that's where we hit the issue. If we're in the situation where COBOL
> is using C (such as, XML PARSE or GENERATE), so LE has changed the PSW to
> no longer ignore the overflows, and LE has lost its condition handler, and
> the COBOL code has an overflow, and ON SIZE ERROR was coded, you still get
> a program check. For example, a S0CA in a VAP or VPS instruction. But
> unlike arch 11 and below, there's no work-around.
>
> Development doesn't want to add the "use larger fields" logic to the
> generated vector instructions, like they do for the non-vector generated
> code, because if they did, the generated vector code wouldn't be as fast as
> the code that is generated that allows the program check with ON SIZE ERROR.
>
> I say, "but COBOL semantics require code in ON SIZE ERROR to not
> overflow". They say I need to prove that.
>
> There solution is to a) don't use arch(12), or b) make your fields larger
> so they don't overflow, or c) add logic around every possible overflow that
> calls an assembler program to save and restore the overflow mask bits.
>
> What do you think? Am I crazy to think that the compiler should generate
> the vector decimal instructions to not do a program check when ON SIZE
> ERROR is coded?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--

Re: RACF, external password management

[Michael Brennan]

Both ACF2 and Top Secret have common phrases that can not be used for
passwords and you can add or subtract from the list.  You would think RACF
would have the same. I have not dug through the RACF manuals to determine
if it does or not.

On Thu, Feb 29, 2024 at 12:09 AM Timothy Sipples  wrote:

> Linda Hagedorn wrote:
> >My company wants an external password manager to substitute for RACF.
> >I need to know if anyone has experience with this, or common password
> >matching in RACF.
> >Background
> >Regulations NYDFS require preventing common passwords to be used.
> >Vendor tools (Courion, CyberArk, etc.) have a corpus to match password
> >changes to prevent the use of common passwords.
> >RACF passwords can be changed from TSO, the internal reader, JCL,
> >Candle Session manager, etc., so trying to block password changing through
> >RACF and forcing everyone through one of these 3rd party tools may be near
> >impossible.
> >Any input is appreciated.
>
> This’d be easy to do with IBM Z Multi Factor Authentication (ZMFA).
> Despite its name you could use ZMFA to support a single “external” factor
> such as a super vetted passphrase verifier, although it’d obviously be best
> to have a genuine second factor too (while you’re at it).
>
> Let’s suppose for example you maintain/update these super rule compliant
> passphrases in a LDAP server. OK, then configure ZMFA so that it validates
> passphrases against the LDAP server and gives RACF yes or no decisions. You
> could for example use “out-of-band” authentication so that users who clear
> the ZMFA hurdle (log in via a secure Web page) get a one-time token that
> they use to log into RACF (in place of a password). And then you’ve neatly
> solved the problem of handling RACF password/passphrase changes everywhere.
> Other variations are possible — this is just an example.
>
> If you’re concerned about the “What if the LDAP server is down,
> unreachable, or slow?” scenarios then one straightforward solution is to
> use z/OS’s LDAP server and simply keep that LDAP server synced reasonably
> well with another LDAP server. (LDAP supports syncing.) In that case ZMFA
> simply loops back to z/OS LDAP, an ultra short loop. If the syncing is down
> for a little while it’s not a calamity. Or use another LDAP server that
> runs in the z/OS Container Extensions or in a Linux on IBM Z partition.
> LDAP is just an example too, although it’s a common one.
>
> https://www.ibm.com/products/ibm-multifactor-authentication-for-zos
>
> —
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity
> IBM Z/LinuxONE, Asia-Pacific
> sipp...@sg.ibm.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Michael Brennan

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

Recovery routine for IRB

[Joseph Reichman]

HI

I have tested my recovery routines in many different scenarios. My last step
was to test a asynchronous exit or an IRB. Since many people have told I
don't post my code I'll do so now.

I have tested the asynchronous exit or IRB and it has gotten control however
when I insert H'0' it abends with without the recovery getting control

I take the current TCB or PSATOLD (the same one that was active when I
established the estate and save it in IQETCB so since the IRB runs under the
same TCB that established the estate it (the recovery program) should get
control 

The local lock is held however I don't think the should stop the estate from
getting control

*++ 
  MODULE CESTAE,BASE=12,LOC=BELOW,AMODE=31,RMODE=ANY,   X
TEXT=' ESTABLISH AN ESTAEX ROUTINE'  
 **---*  
 ** LOAD THE ESTAE ROUTINE*  
 **---*  
  MODESET KEY=ZERO,MODE=SUP  
  

  LOAD  EP=GRECOV,ERRET=EXIT0C LOAD THE ESTAEX ROUTINE   
  LRR3,R0 ADDRESS OF ESTAEX ROUTINE TO R3
 **---*  
 ** BUILD PARMLIST FOR ESTAEX ROUTINE *  
 **---*  
  LAE   R4,ESTPARAM   ADDRESS OF PARMS FOR ESTAE RTN 
  USING ESTPARM,R4MAP ESTAE PARMLIST 
  LAE   R15,RETRY RETRY ADDRESS
 STR15,ESTRETRY  SAVE IN PARMS FOR ESTAE ROUTINE
**---*  
** UNCOMMENT THE FOLLOWING 2 LINES   *  
** IF THIS MODULE EXECUTES IN*  
** SUPERVISOR STATE. *  
**---*  
 STR12,ESTLOAD ENTRY POINT TO ESTAE PARMLIST
 MVC   ESTMOD(8),=CL8'CESTAE'  MODULE NAME TO ESTAE PARMLIST
**---*  
** ISSUE THE ESTAEX MACRO*  
**---*  
 ESTAEX (R3),PARAM=(R4),MF=(E,ESTAELST) 
**---*  
** THE FOLLOWING 4 INSTRUCTIONS  *  
** REPRESENTS THE REST OF THE*  
** PROCESSING IN THIS MODULE.*  
** AN ERROR WILL CAUSE RTM TO INVOKE * 
** AN ERROR WILL CAUSE RTM TO INVOKE *  
** THE ESTAEX ROUTINE.   *  
**---*  
*DCH'0' 
  B IRBERR
 ENDMODRESTORE REGISTERS AND RETURN   
IRBERR   DS0H 
 LOAD  EP=IRBPTR  
 LRR5,R0  
*O R5,=X'8000'
 STR5,IRBADD  
  
* 
 USING PSA,0  
 L R4,PSATOLD


*   
*   
*   
 SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=STDSAVE 
*   
 CIRB EP=(R5), X
   RETIQE=YES, X
   STAB=DYN,   X
   MODE=SUPR,  X
   KEY=SUPR,   X
   WKAREA=255, X
   BRANCH=YES, X
   AMODE=DEFINED


*   

  USING RBBASIC,R1  

Re: RACF, external password management

[Timothy Sipples]

Linda Hagedorn wrote:
>This is very promising. Do you know where I can read more about ZMFA?

The documentation landing page is here:
https://www.ibm.com/docs/en/zma

>I'm interested in knowing how to configure the external source, and how
>the token is passed back to RACF, and how long the token lasts.
>For example, if systems programmers are working a problem, we
>wouldn't want the token to expire in 3 hrs.
>Or does the token last for the duration of the session?
>If tso/ispf times out (sysprog is doing research or answering
>mgmt questions), will they have to generate a new token?

If for example you’re configuring ZMFA to use a LDAP server as an “external” 
factor then this landing page has further details:
https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap

I put the word external in quotation marks because the LDAP server could be 
z/OS’s LDAP server or some other LDAP server running on the same IBM Z machine. 
And LDAP is just one example. Many “external” and external factors’ interfaces 
are supported.

You can configure ZMFA for “out-of-band” authentication so that users obtain 
what’s called a “cache token credential” (CTC) to log into RACF (via TSO/E for 
example). You can choose whether the CTC is reusable and how quickly it expires.

https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: RACF, external password management

[Timothy Sipples]

Linda Hagedorn wrote:
>It's one option to force all RACF password changes through a single
>point.  However, there's a lot of ways to reach the password change
>process in MVS, and writing blocks for all of them isn't reasonable.
>The ZMFA holds promise, if I can find a software company that has
>bought/collected the same 15m passwords that Cybernews did.
>I can route all RACF password changes to the 
>software company for validation.

Not that it’s necessarily the only way to do it, but what I’m thinking with 
ZMFA is that you’d already have passphrases somewhere that have been validated 
(and that are changed and managed) according to your requirements, including 
vetting against previously breached passphrases. These passphrases are already 
residing in an enterprise-wide LDAP server, for example. I’m assuming RACF 
isn’t the only security authenticator that needs to meet this requirement. You 
probably have many other systems and applications that also need to meet this 
requirement, and they’re depending on passphrases stored/managed somewhere.

So, users would stop changing or managing RACF passwords/passphrases. RACF 
wouldn’t even allow it, really, because their user IDs are marked as 
MFA-enabled IDs. That means RACF will loop through ZMFA when they try to log 
in. Users’ would instead first log into ZMFA “out-of-band,” provide their 
enterprise LDAP-stored passphrases, and get back 8 character tokens that 
expire. These tokens can be one-time use or multiple use (always within their 
validity periods). Users then treat the 8 character token as a RACF password to 
log in RACF, and since the user ID is MFA-enabled RACF checks with ZMFA that 
the token/password is valid. ZMFA says, “Yes, that’s the user I just gave that 
token to, it’s not an expired token, and (if one-time use) it hasn’t been used 
before” then tells RACF it’s OK to let that user in. When a user wants to 
change his/her passphrase they do that in the enterprise passphrase database, 
against that LDAP server, not in RACF at all. (They don’t get the opportunity 
to do so. Effectively they’re changing their password every time they grab a 
new token, and that password can be one-time use and always has a relatively 
short validity period.)

As Radoslaw Skorupka wisely pointed out, a passphrase, no matter how well 
managed and vetted, is only one factor. It’s best to authenticate with a second 
strong factor and the passphrase. ZMFA can do this, too. It has “Multi” in its 
name, after all. :-) You can adopt ZMFA in a phased approach if you’re not 
ready to add the second factor immediately. For example, you could first 
require “privileged” users to provide vetted/well-managed passphrases (stored 
in a LDAP server for example) to get their RACF log-in tokens. Then extend this 
requirement to every RACF user ID (except non-human machine ones of course). 
Then require “privileged” users to log in using 2 factors (the 
vetted/well-managed passphrase plus a 6 digit code from an IBM or Google 
authenticator app on their mobile device, for example). Then extend 2 factor 
authentication (2FA) to every user.

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: RACF, external password management

[Timothy Sipples]

Michael 
Brennan
 wrote:

>Both ACF2 and Top Secret have common phrases that can not be

>used for passwords and you can add or subtract from the list.

>You would think RACF would have the same. I have not dug through

>the RACF manuals to determine if it does or not.



RACF has a new-passphrase exit called ICHPWX11. IBM provides a sample exit 
routine, and you can use REXX to run whatever passphrase quality checks you 
wish. The REXX script could even make an external (or “external”) network call 
to check the passphrase against some database. But you’d have to write and 
maintain this REXX code, and it wouldn’t provide multi-factor authentication. 
It’d merely help strengthen new passphrase selections.



https://www.ibm.com/docs/en/zos/3.1.0?topic=users-assigning-password-phrases

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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