The Multi-Factor Authentication part I post described the initial MFA configuration, the enrollment process and second factor authentication with the Mobile Authenticator One-Time Password.
In this second post, we will go over the other factors: security questions, notifications, text messages and bypass code – and the additional security constraints for MFA in general.
In the first post we already discussed the basic settings required to enable MFA, that is, we set MFA for All Users, set it as Optional and we configured the One-Time Password with the Mobile Authenticator as one of the factors available.
The additional settings we can tweak for Multi-Factor Authentication are found under the “Multi-Factor Authentication Settings” page.
Go to the Security tab and click on MFA on the right-side menu.
Besides the configuration options we already discussed in the first part of this post series, we have the following settings as per the picture below.
The "Enable Trusted Computer" is what we all know as "remember my computer".
If checked, users will be presented with the option to mark their computers as "trusted" during login.
That means the next time the user attempts to login, he won’t need to provide the second authentication factor, for a defined period of time (Number of days a computer can be trusted) and for a maximum of devices (Max number of trusted computers).
For increased security, uncheck this to force users to always provide the second authentication factor when logging in.
The Identity Cloud Service administrator can also set the maximum number of factors a user can enroll in.
This setting is controlled by "Max number of enrolled factors".
If the user tries to enroll in more factors than permitted, he would see a message like the picture below.
And lastly, the administrator can set the maximum number of failed Multi-Factor Authentication tries before the user account is locked.
A user can select which Multi-Factor Authentication factors to enroll at the first time he authenticates or at any time by accessing his profile, then clicking on 2-Step Verification tab and by clicking on "Manage".
In the following sections we will cover in details each of the authentication factors available.
The security questions are one of the simplest factors, and most users are familiar with it.
It consists of predefined questions that a user provides answers for and which only the users (or a really close person) would know the answer.
The important constraints an administrator can set up for Security Questions are the number of security questions a user must set up, the minimum answer length (this would help avoid users providing an easy guessing answer) and the number of questions the user is asked as a second factor authentication at login time.
NOTE: When user is challenged by the Security Question as a second authentication factor, the questions are randomly selected from the questions the user has chosen and set up at enrollment time.
In the Manage Security Questions section, the Identity Cloud administrator can enable/disable a security question by checking/unchecking the box for the appropriate question.
Administrators can also add custom security questions.
To do so, click "Add Question" and provide the question in the default language (English) and the translations for other languages.
Note: Only custom security questions can be edited and deleted.
For more information on how to configure Security Questions, see the online documentation here.
When users are requested to set their Security Questions, they should see a screen like the picture below.
The user would have to provide answers for the questions he’s allowed to choose amongst the number of questions enabled/set by the administrator.
When users are challenged by the second authentication factor, and choosing Security Questions, they are presented with a screen like the picture below.
TIP: By clicking on the textbox a pop-up appears with the user security question hint.
NOTE: When users are challenged by security questions as a second authentication factor at login time, the question is displayed in the browser language preference.
Text messages or SMS are a Second Authentication factor sent to the user’s registered mobile number.
This factor is recommended for users without internet connectivity.
The Identity Cloud Service administrator can specify the SMS passcode length, duration and create a custom message template.
For more information on how to configure SMS settings, consult the online documentation here.
The user can register his mobile phone to receive SMS messages at enrollment time.
Identity Cloud Service will send a confirmation code to verify the user phone number.
After the code is verified, the user can start receiving SMS passcodes to authenticate with this cloud account.
Bypass code is a Second Factor code that can be used in case the user doesn’t have access to his other second factors, like the Mobile Authenticator or access to his mobile device to receive SMS texts.
Bypass codes can be user-generated, that means generated by the user himself at enrollment time, or generated by an administrator (help-desk user) on user request.
A bypass code user-generated never expires but can be used only once.
Users can generate their bypass codes by accessing their profile (or at first authentication after MFA is enabled) and clicking in "Generate Bypass Code" button.
Alternatively, an admin user (help-desk) can generate a bypass code for the user by going into the user profile page and selecting the drop-down labeled "More" and choosing "Generate Bypass Code".
The help-desk generated bypass code can have a defined expiration date or can be set to never expire.
It can also be set to be used once, for limited a number of times, or unlimited times.
In the previous post we discussed the Mobile Authenticator and its One-Time Passcode as a second authentication factor.
The Mobile Authenticator can also receive push notifications that can be used as a second factor authentication with your Identity Cloud Service.
In order to allow users to receive push notifications, the Identity Cloud Service administrator should set the App Protection Policy and Compliance Policy for the Mobile Authenticator as the default policy is 'NONE' which isn’t recommended for security reasons we will describe in the following sections.
It is important to properly define the App Protection Policy based on your security requirements carefully.
One of the most important setting is App Protection, which will always require the user to use a PIN or a fingerprint biometric authentication to unlock the Mobile Authenticator app.
Others important settings to consider are "Maximum consecutive attempts before the app is locked", "Lockout Duration" and "Lockout escalation pattern".
Together they can greatly increase the Mobile Authenticator security, and avoid unauthorized access to the app.
For more information on the App Protection Policies, see the online documentation here.
The Compliance Policy governs which operating systems and which versions the OMA app is allowed to be installed on, and the most relevant options are the "Minimum OS version check" and the "Rooted Devices check".
Outdated or rooted device can lead to serious security breaches that can compromise the Mobile Authenticator - this is one of the setting that deserves careful attention from the administrator.
NOTE: every time the administrator makes changes to the OTP default settings, users must re-enroll the mobile app. This applies to users who enrolled the mobile app using the offline QR code or manually entered the key. Users will need to use another verification method or a bypass code to log in and re-enroll.
For more information on the Compliance Policy, see the online documentation here.
When the end-user tries to login and chooses Push Notification as a second factor for authentication, he will see the following screen saying that a notification has been sent for his mobile device.
In his mobile device the user would get a push notification alert, like the one below.
By opening the Oracle Mobile Authenticator app, the user is presented with the notification and login request details, such as the account trying to log in, IP Address, Date and time, and the browser.
The user can choose "Deny" to block the authentication, if he does not recognize the access, or "Allow" to proceed with the authentication.
After allowing access, the mobile app will securely communicate with the Identity Cloud Service to allow the authentication to proceed, and the Oracle Mobile Authenticator will reflect the user decision.
After a few seconds the user’s browser will be refreshed and access will be granted to the user trying to authenticate to the Cloud Service.
The full documentation for Multi-Factor Authentication with Oracle Cloud can be found here.