Overview of Authentication

When a user logs on to a z/VM system, he or she must supply an authenticator to prove their identity. RACF has several methods available to authenticate the user ID, and part of the planning process is deciding which method(s) are right for the different user IDs on the system. These methods include:
Password
A password is a traditional 1- to 8-character alphanumeric value. The simplicity of passwords can present a relatively easy point of attack for exploitation. In order for systems that rely on passwords to be secure, they must enforce password controls and provide user education. Some of the common problems with having a simple password are that users tend to choose common passwords, write down their passwords, and/or unintentionally install malware that can log and forward passwords to the attacker.
Password Phrase
A password phrase (passphrase) is a character string consisting of mixed-case letters, numbers, and special characters including blanks. Password phrases have security advantages over passwords in that they are long enough to withstand most hacking attempts yet are unlikely to be written down because they are easy to remember.
Multi-Factor Authentication (MFA)
A more secure option than the common password or password phrase authentication is for systems to require multiple authentication factors to verify the user's identity. A multi-factor authentication system requires that multiple authentication factors be presented during logon to verify a user's identity. Each authentication factor must be from a separate category of credential types:
  • Something you know – a password or security question
  • Something you have – an ID badge or cryptographic token device
  • Something you are – a fingerprint or other biometric data.
By requiring multiple authentication factors, a user's account can not be compromised if one of their factors is discovered. IBM Multi-Factor Authentication for z/VM provides support for authenticating with multiple authentication factors. RACF users can be configured to require authentication through MFA. For these select users, RACF calls MFA to help in making the authentication decision during log on processing.

Recommendations for Human Users

For human users, the choice of the type of authenticator(s) to assign will depend on your policy, and on which applications are used by the user:
  • If you have many customers/clients or general employees logging on, you do not want their passwords/passphrases written down. Multi-Factor Authentication (MFA) with the NOPWFALLBACK option allows these users to logon with the most secure method. For more information on MFA, see Multi-Factor Authorization.
  • If the user authenticates to z/VM using an application that does not support password phrases or MFA, the user must be assigned a password. In this case, if the user also logs on directly to CP, the user can also be assigned a password phrase. For more information, see Passwords and Password Phrases and Using the Secured Signon Function.

Recommendations for Service Machines and Linux Guests

Disconnected service machines and multi-user operating systems like Linux on IBM Z® should be created as protected users. Protected users do not have a password, password phrase, or any other enabled authentication method and can only be started by using XAUTOLOG or LOGONBY. Any direct human access to these guest's terminals should be authenticated and authorized using LOGONBY and human user IDs, creating a personalized audit trail. For more information, see Defining Shared User IDs.

Recommendations for MFA Authentication

A limited set of employees who maintain the system and administrate RACF for VM should be permitted to LOGON with FALLBACK for circumstances when MFA might be unavailable, unresponsive or configured incorrectly. PWFALLBACK allows these user IDs to logon with a password or passphrase independent from the availability of MFA with LOGON FALLBACK.

Because MFA is often not a good fit for IDs that are used for automation purposes such as automatic data transfer via FTP, it is recommended that you use strong password phrases to authenticate these user IDs if direct access is necessary.

Sufficient time should be allocated at the initial implementation of the MFA authentication policy for training and preparation. Users should be informed about the different characteristics of the implemented policy and factors and the authentication limit and validity period of the derived MFA credential.

For more information on MFA, see Multi-Factor Authorization.