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 <currently unidentified> >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
