Configuring authentication factors
Verify supports
two-factor authentication. It's a type of multifactor authentication that involves the use of a
second factor, typically a system-generated code that the user must provide to prove their identity.
Enforce the use of a second authentication factor for more security control on users when they sign
on to any
application that is developed and integrated with Verify. Choose which second
authentication factor to prompt users. .
Before you begin
- Watch a Verify multifactor authentication video in the IBM Security Learning Academy.
- You must have administrative permission to complete this task.
- Log in to the IBM® Security Verify administration console as an Administrator.
About this task
An OTP is valid for a specific time. It becomes invalid after a successful user login or when it expires.
Procedure
- Select Authentication > Authentication factors.
- Set the general multi-factor authentication settings
- Select the action when no authentication factors exist for the user.
- Deny the authentication.
- Give the user the option to enroll a factor.
- Select the allowed source for the authentication factor.
- User-enrolled methods
- User profile attributes and enrolled methods
- Select whether to notify users when changes are made to their MFA
settings.
- No notifications
- Notify by email
- Notify by SMS
- Notify by any available method
- Notify by all available methods
- Specify whether the user can override change notifications
- Don't allow user overrides
- The MFA change notification options set on the tenant must be used.
- Allow user to override
- The users can change the MFA change notification options to customize their experience.
- Required
- MFA change notifications cannot be turned off by the user. The user must have at least one method available for MFA change notification.
- Select the action when no authentication factors exist for the user.
- Select whether to require users to have multiple MFAs for
authentication. Note: Enrollments must be unique. For example, if you use the same phone number for SMS and VOTP, it is only one enrollment. If you use your cell phone number for SMS and your office phone number for VOTP, then they are two enrollments. Similarly, if your username and email address are the same, it is one enrollment. However, if you list multiple email addresses, they are each an enrollment. For example, johndoe@outlook.com, johndoe@gmail.com, johndoe@mycompany.com are three unique enrollments.
- Select the Set minimum number of enrollments checkbox to set
the number of multi-factor enrollments that the user must have. The requirement is timestamped with the current date. As of that date, users are required to set up their minimum multiple MFA enrollments when they log in to their applications.
- Optional: You can select the Allow end users to skip
enrollments checkbox to set a grace period for existing users. Note: This option allows users to skip enrollments only when they already have one or more enrollments to perform second-factor authentication. Otherwise, they must enroll in at least one second-factor enrollment to enable this option.During the grace period, users can still log in to their applications without the required MFA enrollments. After the grace period expires, users cannot access their applications until they fulfill the multiple MFA requirement. The grace period is based on the start date timestamp. For newly enrolled users, the grace period starts after their registration.
- Select at least one identity provider that the minimum MFA requirement applies
to. You cannot save your changes until you select at least one identity provider. Select the Identity providers checkbox to apply the requirement to all the identity providers.
- Select the Set minimum number of enrollments checkbox to set
the number of multi-factor enrollments that the user must have.
-
Select the authentication factors
that you want to enable or disable for your Verify users.
Note:
- When selected, the authentication factor is enabled for runtime use and its configurable settings are displayed.
- You can enable multiple authentication factors. If you do, users are prompted to choose their preferred method before the one-time password is delivered and validated.
Authentication Factor Descriptions General multi-factor authentication (MFA) settings - When no factors are present during an MFA challenge
- If access to an application requires two factor authentication and no factors are registered, select whether the authentication fails or allow users to register an authentication factor.
- Allow second factors from the following sources
- By default, second factors are allowed from both user profile attributes and enrolled methods. The email and mobile number from the user profile as well as any enrolled authentication methods are available for use as second factor authentications. You can also select to limit the second factors to those authentication methods that are registered in Verify.
Behavioral biometrics Detects behavioral typing anomalies during traditional username and password authentication. Email One-Time Password The password is generated and sent to the user's registered email address.
This option is enabled by default.
Note: The user must have a registered email address. Otherwise, this option is not presented to the user even if it is selected because the one-time password cannot be delivered to the user.SMS One-Time Password The password is generated and sent to the user's registered mobile number.
This option is enabled by default.
Note: The user must have a registered mobile number. Otherwise, this option is not presented to the user even if it is selected because the one-time password cannot be delivered to the user.Time-Based One-Time Password The password is generated by using the standard time-based one-time password algorithm.
Passwords are not delivered or stored, but are verified as a match between a TOTP validation server and a client as they are generated at regular intervals.
The user must first enroll an account by scanning a QR code image or providing the equivalent secret in a TOTP mobile application like IBM Verify or Google Authenticator.Note: The user must have a registered mobile number, and downloaded and installed IBM Verify or Google Authenticator.Voice One-Time Password The password is generated and sent to the user's registered phone number. The phone number can be either for a mobile phone or a land-line phone.
IBM Verify Authentication Authentication is performed through a runtime challenge that verifies that the user is physically present at the device. It can also require a device-based fingerprint authentication. Note: The user must have downloaded and installed IBM Verify or a custom mobile app that uses the IBM Verify mobile SDK. The user must also have a registered mobile authenticator.QR Code Login Configuration An application can initiate a qrlogin verification transaction, then waits for that verification request to be completed by the user with IBM Verify, and then continues the runtime access. See QR login passwordless authentication.
- Optional:
If you enabled Email One-Time Password or SMS One-Time
Password, you can configure the following settings to control its behavior:
Table 1. Email and SMS one-time password settings Information Descriptions Expiry (seconds) How long the passcode is valid. Length The number of characters that are included in the one-time password value.
The minimum value is 1.
The maximum value is 20.
The default is 6.
Password Character Set The set of valid characters that can be included in the one-time password value. They can be alphabetic and numeric characters.
The default value is 0123456789.
Retries The number of authentications failures that are allowed before the password expires and the user must start a new authentication transaction. Allowed domains Specify the email domains that the OTP password message can be sent to. You can specify multiple domains. You can use regex patterns to specify more domains. Denied domains Specify any email domains that the OTP password message must not be sent to. You can specify multiple domains. You can use regex patterns to specify more domains. - Optional:
If you enabled Time-Based One-Time Password, you can configure the
following settings to control its behavior:
Table 2. Time-based one-time password settings Settings Descriptions Hash Algorithm The algorithm that generates the time-based one-time password. The TOTP algorithm uses hash-based message authentication code (HMAC) combined with SHA hash function.
Select from the following options:- HMAC-SHA-1
- HMAC-SHA-256
- HMAC-SHA-512
HMAC-SHA-1 is the default hash algorithm.
Generation Interval (seconds) The maximum number of seconds that the OTP is valid before the next TOTP is generated. After this time, the TOTP generator and server validation generate a new TOTP.
The default value is 30.
Note: Changes to the interval affect only the enrollments that occur after the change. Existing enrollments continue to use the previous value. To use the new value, existing enrollments must be deleted and re-created.Skew Intervals Skew interval is the ± number of intervals from the client device' timestamp, for which the server accepts the generated OTP.
For example: Using the following table that lists the OTP values for seven generation intervals, consider an OTP verification where the current time on the server corresponds to interval0
. If Skew Intervals is set to 2, then the OTP validation can succeed if the user presents any of the OTP values from intervals0
through2
.Interval Time stamp OTP 3 09:00:10
876 123
2 09:00:40
543 456
1 09:01:10
210 789
0 09:01:40
987 012
1 09:02:10
654 345
2 09:02:40
321 678
3 09:03:10
761901
The default value is 1 and the allowed minimum value is 0.
Digits The number of characters that are included in the one-time password value.
The minimum value is 6.
The maximum value is 12.
Secret Key URL The URL that delivers the secret key and generates the QR code.
The URL format might include information specific to your environment, such as your company name.
The default URL is: otpauth://totp/IBM%20Security%20Verify:@USER_NAME@?secret=@SECRET_KEY@&issuer=IBM%20Security%20Verify&algorithm=@ALGORITHM@&digits=@DIGITS@&period=@PERIOD@
Note: The URL must NOT containhttp
orhttps
. It must always start with otpauth://totp/One Time Use Indicates whether to cache the one-time password for reuse when it is used to successfully log in to a target resource.
If enabled, a valid TOTP value can be used at most once at the validation server. If not enabled, a valid TOTP value can be validated more than once during its validity period.
This option is selected by default. When selected, users cannot reuse the password while it is in cache.
Enrollments Per User The maximum number of enrollments that a specific user can enroll.
The minimum value is 1.
The maximum value is 5.
- Optional: If you enabled Voice One-Time Password, you
can configure the following settings to control its behavior:
Table 3. Voice One-Time Password settings Information Description Expiry (seconds) How long the passcode is valid. Length How many characters are contained in the passcode. The length must be at least one character. Character set What characters are can be used in the pass code. They can be alphabetic and numeric characters. Retries The number of authentications failures that are allowed before the password expires and the user must start a new authentication transaction. - Optional:
If you enabled IBM Verify Authentication, you can configure the
following settings to control its behavior:
Table 4. IBM Verify authentication settings Information Descriptions User Presence This authentication factor is supported by IBM Verify or by a custom mobile app that uses the IBM Verify mobile SDK. This authentication factor provides a basic, out-of-band, verification that a user is present and possesses a registered mobile authenticator. The runtime challenge simply requires the user to approve or deny the verification by selecting a UI prompt. Users enroll for this authentication factor as part of the mobile authentication registration process. The enrollment is embodied by the exchange of a public key, which is generated on the mobile authenticator and 'enrolled' with Verify. An approved verification is indicated to Verify when the mobile authenticator signs verification transaction data with the private key, which is stored on the mobile device and is associated with the enrolled public key. - Supported Algorithms
- The cryptographic algorithms that can be used during enrollment and runtime verification transactions and challenges. These settings are transferred to mobile authenticators during the registration process.
- Preferred Algorithms
- The cryptographic algorithm to be preferred for key generation enrollments.
Fingerprint This authentication factor is supported by IBM Verify or by a custom mobile app that leverages the IBM Verify mobile SDK. This authentication factor provides out-of-band verification that a user is present and possesses a registered mobile authenticator. Additionally, the user is required to successfully complete a device-based fingerprint authentication. Users enroll for this authentication factor as part of the mobile authentication registration process. The enrollment is embodied by the exchange of a public key, which is generated on the mobile authenticator and 'enrolled' with Verify. The private key is stored by the mobile authenticator in the device key chain and is protected by device-based fingerprint authentication. An approved verification is indicated to Verify when the mobile authenticator signs verification transaction data with the private key, which is stored on the mobile device and is associated with the enrolled public key. - Supported Algorithms
- The cryptographic algorithms that can be used during enrollment and runtime verification transactions and challenges. These settings are transferred to mobile authenticators during the registration process.
- Preferred Algorithms
- The cryptographic algorithm to be preferred for key generation enrollments.
Face This authentication factor is supported by IBM Verify or by a custom mobile app that leverages the IBM Verify mobile SDK. This authentication factor provides out-of-band verification that a user is present and possesses a registered mobile authenticator. Additionally, the user is required to successfully complete a device-based face authentication. Users enroll for this authentication factor as part of the mobile authentication registration process. The enrollment is embodied by the exchange of a public key, which is generated on the mobile authenticator and 'enrolled' with Verify. The private key is stored by the mobile authenticator in the device key chain and is protected by device-based face authentication. An approved verification is indicated to Verify when the mobile authenticator signs verification transaction data with the private key, which is stored on the mobile device and is associated with the enrolled public key. - Supported Algorithms
- The cryptographic algorithms that can be used during enrollment and runtime verification transactions and challenges. These settings are transferred to mobile authenticators during the registration process.
- Preferred Algorithms
- The cryptographic algorithm to be preferred for key generation enrollments.
- Optional: If you enabled QR Code Login Configuration,
you can configure the following settings to control its behavior:
Table 5. QR Code Login Configuration settings Information Descriptions Expiry The number of seconds that the user has to scan the QR code before it is no longer valid to complete the authentication flow. Login Session Index - Number of Characters
- Specifies the minimum number of characters that must be used.
- Character Set
- Defines the set of alphabetic and numeric characters that can be used.
Device Session Index - Number of Characters
- Specifies the minimum number of characters that must be used.
- Character Set
- Defines the set of alphabetic and numeric characters that can be used.
- Select Save.
What to do next
Set up access policies to determine when to enforce the use of a second factor for authentication. See Managing portal access.