Multi-Factor Authentication (MFA) has become critical mandatory technology for IBM i user signons for two reasons:
- Enhanced security: MFA provides user login security by ensuring that the person signing on with a specific user ID and password is actually the person who owns that user ID and password. MFA validates user identity beyond using just a password, providing enhanced security against stolen user IDs, phishing scams and cyberattacks.
- Regulatory compliance: MFA is increasingly being required by governmental, regulatory, industry and insurance entities. See Everyone Says “My IBM i Needs Multi-Factor Authentication” for more information on what groups now require mandatory MFA compliance.
Today’s post is a primer for understanding MFA usage on IBM i servers. We’ll explain how MFA works and how to implement IBM i MFA for user login security and compliance.
How MFA works
MFA provides tighter security than just entering a single user/password combination for system access (single factor authentication, SFA). MFA provides user login security by helping ensure that the person signing on with a specific user ID and password is actually the person who owns that user ID and password.
Multi-factor authentication (MFA) requires that users present two or more independent pieces of authentication credentials (factors) confirming their identity before they can access a computer resource, such as an IBM i server. Each authentication factor must come from a different authentication factor category (figure 1) in order to gain access to the system. Acceptable authentication factors can come from the following categories:
Knowledge: Something you know, such as a user profile password or the answer to a security question.
Possession: Something you have, such as a digital token, authenticator code or an RSA SecurID device.
Inherence: Something unique to you, such as your fingerprints or facial features that are “read” by a scanning device or a camera.
Two-factor authentication (2FA) is an MFA subset (figure 2) that requires users to supply identifying evidence from exactly two credentials. For MFA verification, a user satisfying 2FA requirements (two authentication factors) will satisfy MFA access requirements for most applications.
MFA in action, an example
A typical example of an MFA process is a standard Web site password reset (figure 3). A user forgets their password and clicks on the Forgot password link. The Web site asks for answers to the user’s security questions (knowledge factor: something they know). The user correctly answers the questions. The Web site texts or emails a One-Time Password (OTP) to the user’s cell phone or email account (possession factor: something they have). The user signs on with the temporary password and the Web site prompts them to change their password. MFA identity requirements have been satisfied.
Implementing MFA on IBM i Servers
IBM i MFA solutions provide similar protections to the example listed above. However, IBM does not offer any native IBM i capabilities for enabling MFA for user and device access. IBM i MFA protection is enabled by using third-party IBM i-based solutions such as iSecurity Multi Factor Authentication (iSecurity MFA). These products can provide MFA services for IBM i logins using multiple interfaces, including:
- Telnet 5250 access
- ODBC access
- Integrated File Server (IFS) access
Here’s a step-by-step overview of how MFA software typically protects IBM I systems from invalid logins.
- Enrollment: Users are enrolled in the IBM i MFA program through an administration interface. This is where admins indicate which users are now covered by MFA security and specify the source of each user’s verification factors (e.g., security questions, cell phone number, Google Authenticator, Microsoft Authentication, etc.).
- Initial Verification for system access: Users enter their first verification factor when starting a new IBM i session. Initial verification is usually accomplished by using their IBM i user ID and password (something they know). Once the first authentication factor information is verified, the system prompts them for a second factor.
- Second Verification Factor: Users must provide their IBM i second verification factor, which can be generated by a mobile app like Google Authenticator, received via email or text message, or obtained through another verification method (something they possess or something they are). This additional factor proves their identity beyond just using their password.
- Successful Login: Once both verification factors are confirmed, the system grants access to the user.
Considerations for Implementing MFA
When implementing MFA on your IBM i systems, consider the following:
- Do you need to use MFA on multiple systems? MFA protection may be necessary for IBM i systems other than your production environment. It’s essential to assess all servers that may require MFA installation, including production systems, development partitions, QA environments, high-availability systems, and any other IBM i servers in your network.
- Are there multiple IBM i interfaces that require MFA implementation? Evaluate the interfaces that should have MFA protection, which may include Telnet access, 5250 logins, ODBC connections, FTP transfers and IFS file server access.
- Should you implement MFA verification by IP location? If the MFA solution permits, consider establishing MFA exemptions and requirements based on user location (IP address). For example, an admin may exempt warehouse workers using scanners from MFA requirements or mandate that out-of-network users provide additional verification credentials.
- How will user enrollment occur? Evaluate how users should enroll in the MFA solution. Can they self-register, be auto-registered, use a combination of both techniques or use user-assisted enrollment?
MFA and 2FA are solid technologies for increasing security and meeting compliance obligations. Contact SEA for more information on implementing Multi-Factor Authentication for IBM i system logins.