IBM i MFA Multi Factor Authentication Solution for iSeries AS400

IBM i MFA is a Multi-Factor Authentication Solution and Password Self-Service (PSS) solution for iSeries AS400 systems that helps prevent unauthorized access of 5250 sign-on, web services and third party applications, by requiring two or more identification or authentication factors from users before allowing access to the IBM i. Multi-Factor Authentication MFA for IBM i is commonly required by compliance regulations for cybersecurity threats which take advantage of weak password and poor authentication policies, such as FFIEC, 23 NYCRR 500 and PCI DSS. IBM i MFA is also commonly referred to as 2FA or Two-Factor Authentication, but the difference being, MFA can require two or more factors. IBM i MFA and 2FA are both native solutions that work with OS400 5250 sign-on credentials, web services and third party applications, and force users to provide user ID and password, plus one or more additional requirements that can include something in their possession (such as a smart phone, token device or corporate email account) or a part of the user (such as a finger print, voice or eye ball).

IBM i MFA Solution allows an administrator to choose between using a single or two-step authentication process, however single-step is the recommended option, as it is the only process that is supported by all compliance requirements and multi-step authentication has been proven to be insecure. When authentication fails in a single step process, the user has no way of knowing which one wrong. Single-step IBM i MFA (AS00 iSeries) requires the user ID and password combination as well as a token for sign-on authentication, whereas two-step presents the token screen after sign-on.

IBM i MFA uses a very flexible and robust rules engine that makes implementation very quick and simple. For instance, Multi-Factor Authentication rules can be triggered for users with limited capability, having special authorities, are a member of a Group Profile, when using a specific device, coming from an IP address range, if sensitive data access or changes need to be made, when logging on to system on a specified date or time range, authenticating from a specific sub-system or independent ASP and or can be invoked manually via command, in a program or by calling the program.

How IBM i MFA Multi-Factor Authentication Works
IBM i MFA forces users to authenticate with at two or more different identification factors (in addition to a user name) for identity confirmation. The identification factors must be from two different categories in order to qualify as true Multi-Factor Authentication MFA. By requiring at least two authentication factors (see below), a hacker has a much less chance of successfully gaining access to a system. Forcing users to answer questions and entering a password, is only single-factor authentication, because the user is providing two forms from the same “something the user knows “ group.

• Something the user knows (e.g.: password, PIN, answers to security questions, passphrase)
• Something the user possesses (e.g.: email account, smartphone, code-generating device)
• Something inherent to the user (e.g.: fingerprint, iris scan, voice recognition)

IBM i MFA requires OS400 V6R1 or higher, and is a RSA Certified solution. You can view the RSA SecurID Access Implementation Guide for RAMi here: https://community.rsa.com/docs/DOC-92160

Multi-Factor Authentication (MFA) versus Two-Factor Authentication (2FA)
Two-factor authentication 2FA is sometimes used interchangeably with MFA, and even some compliance regulations use this term instead of MFA. However, there is a difference. 2FA uses only two authentication factors, whereas MFA can use two or more authentication factors.

Single-Step vs. Multi-Step Authentication MFA – It is IMPORTANT!
Companies should always use single-step authentication, primarily because of security, which is the reason for implementing MFA in the first place. Single-step authentication will prompt a user for all identification and authentication factors using a single screen and validate all factors at one time. Multi-step will prompt users for identification and authentication factors using multiple steps, allowing the hacker to confirm when one is correct before moving onto the next screen. Multi-step authentication is not permitted by some compliance regulations. One could assume others will join the secure band wagon as time goes on, so why risk going down this road? Since single-step validates all identity and authentication factors simultaneously, the person logging on to system has no way of know which factor failed.

Secondary Authentication Factors and Methods
The first authentication factor is usually something the user knows like a password. Secondary authentication factors include Something the User Possesses and Something Inherent to the User. Things a user would likely possess include: landline phone, smartphone, email, or a special hardware device. Something That's Inherent to the User In some organizations, the secondary or even the tertiary factor of authentication is made through something that is inherent to the user, such as fingerprint, iris scan, face recognition, etc. Depending on the method used, the cost of implementing this as a factor of authentication can be high, so it is mostly used by organizations that have particularly sensitive data.

Second factor authentication is typically delivered as a special code, also referred to as a token. These codes are usually only able to be used once and expire in a short period of time after generation. These codes or token will likely be generated using a separate authentication system or service, and delivered to uses by the following means:

• Email (note: users should have a different login for email than for the IBM i for this method to be secure)
• Smartphone app
• Telephone call to landline or mobile number to deliver an audio message to one or more user phone numbers.
• SMS/text message (note: this method has been proven to be insecure)
• Special hardware devices  

MFA Authentication Services
Authentication code can be generated and sent from a variety of sources, based on the authentication method and level of security needed. Some third-party authentication services that can integrate with IBM i MFA to supply authentication codes include:

• RADIUS: is an on premise solution that creates tokens for many platforms.
• RSA SecurID: sends a one-time use code that expires in 60 seconds from an on premise hardware, software or a smartphone.
• Authy from Twilio: uses a mobile device that does not require a cell connection, landline or browser to provide time-based, single-use codes on demand.
• TeleSign: Sends authentication codes by mobile and voice.
• YubiKey: Uses a thumb-drive device to provide codes.

Password Self-Service PSS and User Profile Enablement Self-Service
If you are implementing multi-factor authentication, you might as well utilize the features that will reduce your Help Desk and administration costs by allowing users to use the Password Self-Service PSS feature. IBM i MFA includes a User Self-Service portal for secure password reset and profile re-enablement, while benefiting from the security of multi-factor authentication technology. By implementing IBM i MFA, users can securely re-enable their own profiles or change a forgotten password without support from the Help Desk or an administrator. Using the PSS feature, users can answer preconfigured questions and/or receive a single-use code sent by a pop-up window, email, or hardware device before making changes to their profile.

Use 4 Eyes Risk Control for Very Sensitive Data
Four eyes principle is a process used when requirements dictate two people to be present at the same time an access or change occurs. This extreme protocol is not very common, but a few environments may have a need to ensure very sensitive data has these safe guards in place, allowing supervision of access or changes where significant risk exist. IBM i MFA allows for Four Eyes principle to be invoked using its rules engine, so if a user needs to perform a sensitive change or operation, a designated supervisor will receive an email with a single-use token with the user’s information making the request. The supervisor will enter the token into the user's screen and observe the change or operation while it is being made.

Before choosing an IBM i Multi-Factor Authentication MFA solution, consider the following:

• Does it support 5250 sign-on, third-party applications such as ERP, HR, web applications and other processes and services running on your IBM i?
• Does it use single-step authentication?
• Is it flexible enough to be implemented how you envision and to meet compliance: invoked by Group Profile, Special Authority, IP Address, Device Type, Date/Time, Program, sub-system, iASP, etc.
• Does it integrate with IBM i native auditing, security controls and policies, such as exit programs and profile swapping “elevated authority” rules?
• Is the requirement for two factor authentication or more than two?
• Is “four eyes principle” required for supervision of sensitive data access or changes?
• Does it meet all compliance requirements?

Make sure the IBM i MFA solution has the features and flexibility needed to invoke multi-factor authentication processes for all user access requirements, and integrate with all OS400 sign-on, web services, applications and processes at a granular level. There may even be specific use case requirements when you will need to invoke MFA when a user accesses a powerful application or when a user has to change sensitive data. Like other security and compliance related processes, auditing is critical. The IBM i MFA solution should use a secure file or journal (such as QAUDJRN) that captures an un-editable audit trail. If your company uses a SIEM or SYSLOG Server to monitor and centralize security events, keep this in mind for the MFA solution you choose also. The audit log should capture MFA application configuration changes and authentication failures.

IBM i MFA is a security and compliance solution for protecting sensitive data from being accessed by hackers and internal users with bad intentions. Contact us with questions, pricing, to schedule a demonstration or download a trial for a proof of concept.