Multi-Factor Authentication

Multi-factor authentication (MFA) is a security measure that allows a user to register additional pieces of evidence (or “factors”) to protect their identity, like a backup mobile number or a third-party app. 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 a 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.

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

MFA Types

Storefront Gateway AuthN ID – the user registers one of their verified Storefront Gateway 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, Storefront Gateway issues an action token 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, and the client then passes the OTP back to Storefront Gateway in a Process Step request.

Redeeming the Storefront Gateway Action Token
As a general rule, Storefront Gateway action tokens are redeemed with the 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 Process Step Process Step request.
Authenticator App – the user registers an RFC 6238 compliant third-party authentication app to their Storefront Gateway User ID as an MFA secondary factor using the Register Authenticator App as MFA Process. If MFA is triggered, Storefront Gateway calls the Authenticator service, and the application then sends a Time-based OTP (TOTP) to the user. The user supplies that TOTP to the client UI that then passes the TOTP in a Process Step request.

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 attacker controls the victim’s phone number and can receive MFA codes. Note: 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. 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-compliant app. Known apps include:

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

MFA Trigger Criteria

Storefront Gateway triggers MFA challenge when the following three conditions are met:

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

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

a user invokes the Authenticate User Process with their authN ID and password.
- If the supplied credentials are valid, the Process prompts for MFA.
a 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 Storefront Gateway.
- Storefront Gateway discovers an existing Storefront Gateway 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.

Trusting Devices

When a Storefront Gateway Process prompts for an MFA check, it also allows the user to specify whether or not they want to trust the device. Trusting a device means that Storefront Gateway Processes will not prompt the 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 prompt from the Authenticate User Process:

**MFA Prompt**
{ 
   "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 Storefront Gateway as an attribute on the User-to-Runtime association. Storefront Gateway does not prompt for MFA during sign-in from trusted devices. End users may wish to “trust” devices which are always under their control (e.g. home set-top boxes or desktop computers). End users should not trust devices they do not always have access to or do not own (e.g. a friend’s laptop). End 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). Note: End users who enable MFA on their profiles must be aware that, by 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), it may be more difficult to recover your account/access (depending on customer service policies). Organizations may not 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. Parent topic:User Authentication

Home

Introduction

For Merchants

For Resellers

Partner Ecosystem Management

Commerce Engine

Storefront Experience

APIs

MFA Types

MFA Trigger Criteria

Trusting Devices

​MFA Types

​MFA Trigger Criteria

​Trusting Devices

MFA Types

MFA Trigger Criteria

Trusting Devices