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. Watch a Verify multifactor authentication video in the IBM Security Learning Academy.

Before you begin

  • You must have administrative permission to complete this task.
  • Log in to the IBM® Security Verify administration console.

About this task

The first authentication factor is typically the username and password, a QR code, or a FIDO device. The second authentication factor is something the user has, typically an automatically generated numeric or alphanumeric code that is sent to the user. Verify uses IBM Verify app, Authenticator App, FIDO, and one-time password (OTP) as the second factor for authentication. The OTP can be delivered through email, SMS, Voice, or it can be time-based and validated with no delivery mechanism.

An OTP is valid for a specific time. It becomes invalid after a successful user login or when it expires.

Procedure

  1. Navigate to Security.
  2. Select the Authentication factors tab.
  3. 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.
    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 FIDO device, see Managing FIDO2 devices.
  4. 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.
  5. 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' time stamp, 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.

    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.

  6. 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.
  7. 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 clicking 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.
  8. 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.
  9. Click Save.

What to do next

Set up access policies to determine when to enforce the use of a second factor for authentication. See Managing the portal access policies for the administration console and home page.