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. .

1. Select Authentication > Authentication factors.
2. Set the general multi-factor authentication settings
   1. Select the action when no authentication factors exist for the user.
      • Deny the authentication.
      • Give the user the option to enroll a factor.
   2. Select the allowed source for the authentication factor.
      • User-enrolled methods
      • User profile attributes and enrolled methods
   3. 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
   4. 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.

3. 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.
   1. 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.
   2. 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.
   3. 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.
4. 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.

   Note: To enable authentication by using a passkey, see Managing FIDO2 devices.
5. 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.

6. 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 interval 0. If Skew Intervals is set to 2, then the OTP validation can succeed if the user presents any of the OTP values from intervals 0 through 2. 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 contain http or https. 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.

7. 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.

8. 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.

9. 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.

10. Select Save.