Multi-Factor Authentication (MFA)

Content

• Overview
• MFA Types
• MFA Trigger Criteria
• Trusted Devices
• Revision History

Overview

ULM Cloud offers support for multi-factor authentication, and enables end users to better secure their User IDs against malicious attacks.

Multi-factor authentication (MFA) is a security measure that allows an end user to register additional pieces of evidence (or "factors") to protect their identity, like a backup mobile number or a third-party app.

If an end user attempts password-based authentication from a new or unknown device, and there is one or more secondary factors registered with their ULM User ID, then ULM Cloud prompts the user to supply proof of their identity, using one of those factors, before the system proceeds.

End users commonly reuse passwords across multiple websites/services. If a malicious attacker discovers a password and compromises one service that belongs to a user, the attacker could use the same password to access other important services or resources that the user owns. MFA prevents the compromise of an end-user's ULM User ID in the event that their single factor (e.g. password) is compromised because, even with the correct username and password, an attacker is stopped by the need for evidence that they cannot produce.

MFA Types

By default, ULM supports the following methods or types for MFA:

ULM AuthN ID

The end user registers one of their verified ULM authN IDs (i.e., email or mobile) as an MFA secondary factor, using the Register Email or Mobile as MFA Process. If MFA is triggered during an authentication attempt, ULM Cloud issues a ULM Action Tokens as a short form, custom One-time Passcode (OTP) and sends it to the external channel. The user then supplies that OTP to the client UI that then passes the OTP in a PUT /process/step request.

Redeeming the ULM Action Token

As a general rule, ULM action tokens are redeemed with the GET /session/token API, wherein the token value is provided in the API request URL. However, this scenario is an exception wherein the client application must instead provide the OTP (and PKAT) in the body of a PUT /process/step request.

Authenticator App

The end user registers an RFC 6238-compliant third-party authentication app to their ULM User ID as an MFA secondary factor, using the Register Authenticator App Process. If MFA is triggered, ULM Cloud calls the Authenticator service, and the application then sends a Time-based OTP (TOTP) to the end user. The user supplies that TOTP to the client UI that then passes the TOTP in a PUT /process/step request.

As a best practice, end users should be encouraged to leverage mobile Authenticator Apps. If an attacker discovers that MFA is in use, they may then target their attacks against the secondary factor itself.

For example, if an attacker discovers that an email address is the second factor, they may target the email account in order to gain access and retrieve MFA codes for verification. Conversely, mobile phones are more commonly the victim of an attack called "simjacking," wherein persistent attackers call the carrier's customer service line and pretend to be the user that they are attacking, in order to transfer service to a SIM card under the attacker's control. If successful, the attack controls the victim's phone number and can receives MFA codes.

Authenticator Apps are not subject to remotely-operated attacks such as these; the apps can only be compromised by physical access to an unlocked device

Supported Authenticator Apps include any RFC 6238. Known apps include:

• Google Authenticator
• Microsoft Authenticator
• LastPass Authenticator (LogMeIn, Inc.)
• 1Password (AgileBits, Inc.)
• Authy (Twilio, Inc.)

Coming Soon - Expanded MFA Options: Native support for additional MFA options are currently in development, including:

• Biometrics signatures, like a fingerprint or facial scan that the user. ULM Cloud already includes tertiary support for biometrics in that supported third-party social providers and authenticator applications that support biometrics can still federate authentication back to ULM Cloud.
• Device based authentication, such as a USB authentication key. ULM Cloud includes support for FIDO security key. Documentation for this support is forthcoming in a near-future release.

MFA Trigger Criteria

ULM Cloud triggers MFA challenge when the following three conditions are met:

• The active ULM Process prompts the user to supply a password for authentication.
• The user has at least one MFA secondary factor registered to their ULM User ID.
• The user is attempting to authenticate from an unknown device.

Currently MFA support has been implemented with two specific Process-driven scenarios:

• An end user invokes the Authenticate User Process with their authN ID and password.
  • If the supplied credentials are valid, the Process prompts for MFA.
• An end user invokes the Onboard and Authenticate User with Social Account Process. The following conditions apply:
  • The Process calls the specified social provider.
  • The provider returns an email or mobile to ULM Cloud.
  • ULM Cloud discovers an existing ULM User ID with the registered email or mobile.
  • The User ID does not have an association with the social account.
  • The Process prompts the user for their password, to prove that they own this User ID.
  • If the supplied credentials are valid, the Process prompts for MFA.

Trusted Devices

When a ULM Process prompts for an MFA check, it also allows the end user to specify whether or not they want to trust the device. Trusting a device means that ULM Processes will not prompt the end user for a verification token on every subsequent authentication attempt from that particular device. End users may wish to "trust" devices which are always under their control (e.g. personal phones, laptops). Conversely, end users should not trust devices they do not always have access to or do not own (e.g. public computers).

Below is an example of the MFA prompts from the Authenticate User Process:

{
   "processId":"eec918ff-5db4-4fee-a601-5ff76a099c8e",
   "processName":"authentication.AuthenticateUser.v1.0",
   "stepName":"TwoFACodePrompt",
   "displayMessage":"Please input required information",
   "output":{
      "pkat":"babec3b7-96b5-47f4-b697-4683820d55af",
      "attemptsRemaining":5
   },
   "parameters":{
      "code":"String",
      "pkat":"String",
      "trustedDevice":"Boolean"
   }
}

The client UI should include a checkbox for the user to signify whether or not they want to trust the current device from which they are authenticating. If the user opts to trust the device, that relationship is then saved in ULM Cloud as an attribute on the User-to-Runtime association. ULM Cloud does not prompt for MFA during sign-in from trusted devices.

Users may wish to "trust" devices which are always under their control (e.g. home set-top boxes or desktop computers). Users should not trust devices they do not always have access to or do not own (e.g. a friend's laptop). Users are free to revoke trust from devices at any time, should the trust be broken (e.g. the user selling their mobile phone to someone else, or on fears a device has been compromised).

Important: End users who enable MFA on their profiles should be made aware that recovering their profile, should they lose their password and/or second-factor (e.g. if they receive verification codes by SMS, but their phone number changes), may be significantly more difficult that normal, depending on customer service policies. Organizations may not wish to allow customer service agents to disable two-factor authentication on user profiles on behalf of a user, if that user has no way to prove their identity to the customer service agent.

Revision History