Adaptive Multi-factor Authentication
Adaptive MFA (Multi-factor Authentication) enhances the security of your portal or web application using a combination of risk analysis techniques and multi-factor authentication.
An Adaptive MFA Policy contains the following settings:
Strivacity Fusion provides several login workflows for you to choose from depending upon the customer journey that you wish to create.
Because a login workflow can be defined for an Adaptive MFA policy, it means that you can have multiple Applications each with its own Login Workflow, giving you flexibility to provide different customer journeys per application.
Login Workflow | Journey Description |
Username → MFA → Password | This is the default workflow for Fusion and is included within the default Adaptive MFA policy. This will provide a customer journey that requires the customer to provide the username as the identifier, then an MFA method (as defined within the Multi-factor Authentication section of the policy) and then the Password. This workflow uses the MFA method to prevent an attacker from locking out the customer's account by exceeding the permitted number of password attempts. |
Username → Password → MFA | This will provide a customer journey that requires the customer to provide the username as the identifier, and then they will be required to provide their password, followed by the MFA method (as defined within the Multi-factor Authentication section of the policy). |
Passwordless (Username → MFA) | The passwordless login workflow will not require the customer to use a password at all. The username is still used as the identifier, however, instead of using a password this will only require an MFA method to be used. While it can be argued that using MFA and not using a password is just using a single factor, it removes the attack vector of the secret (the password) being stolen (and used) by an attacker entirely. |
Username → Password (single factor only) | The username and password workflow is just that! |
Multi-Factor Authentication (MFA) provides an additional layer of security beyond just a (single factor) username and password based authentication.
Multi-Factor Authentication protects your customers against threats such as,
Account Takeover
Unauthorized Account Access
Fraudulent Transactions
Account Hijacking
Fusion provides the following Multi-Factor Authentication methods:
Method Type | Security Posture | Ease of Adoption | Coverage | Usability |
Password | Weak | Easy | Broad | Easy |
Voice Call Passcode | Moderate | Easy | Broad | Medium |
SMS OTP | Moderate | Medium | Broad | Medium |
Email OTP | Moderate | Medium | Broad | Medium |
SMS Magic Links | Strong | Easy | Medium | Easy |
Email Magic Links | Moderate | Easy | Broad | Easy |
Google Authenticator/ or other Soft Token | Strong | Medium | Medium | Medium |
Fusion provides a fully included and managed SMS and Voice Call service with global coverage. No further configuration or need to subscribe with a third-party service provider is required - meaning that there is nothing additional to configure or setup to start using Fusion's supported phone-based Multi-Factor Authentication methods.
See Customizing SMS Templates for more information on how to use your own branding and customize the way in which SMS messages are sent.
Fusion provides a fully included and managed Email service. No further configuration or need to subscribe with a third-party service provider is required - meaning that there is nothing additional to configure or setup to start using Fusion's Email notifications or supported Email-based Multi-Factor Authentication methods.
See Customizing Email Templates for more information on how to use your own branding and customize the way in which Email messages are sent.
Fusion Adaptive MFA policies include several risk analysis techniques that can adjust and enhance the customers registration or login journey.
Fusion includes several workflow options that can be used where they make sense during registration, login or password reset.
Outcome | Description |
Step-up Authentication | When risk is detected during authentication, a step-up authentication can be triggered. This only applies where Multi-Factor Authentication is configured and will require the customer to respond to an Multi-factor Authentication challenge. |
Deny Authentication or Registration | When risk is detected during authentication (log in), or during self-service registration, the request can be denied, meaning the customer will not be allowed to proceed because the risk level is deemed to be too high. |
Redirection | When risk is detected during authentication (log in), or during self-service registration, the customer can be redirected to an alternative URL (web page) of the admin users choosing. |
Fusion's geolocation detection resolves IP addresses to physical locations using a highly accurate and frequently updated resolution database.
Why is this useful? geolocation detection allows brands to specifically allow or deny customer registration or log ins from any geography that they do or not want customers to use their application or website. This helps reduce attack surface and provide great assurance to any requirements or law around where an application or website can be access from.
This capability allows an admin to change the customer journey based on specific locations at a granular level - the Entire World, Country, State, and City levels - with worldwide coverage.
When configuring geolocation detection, the most restrictive options will always apply. For instance, if you deny registration/authentication from the UK (Country), and then allow registration/authentication from Sheffield (a City within the UK) then any registration or authentication requests from Sheffield will still be denied.
With geolocation detection you can;
1) Allow Registration/Authentication - the ability to define an allowed list of physical locations that a customer can self-register from or log in from.
2) Step-up Authentication - if multi-factor authentication is enabled and an existing customer logs in in from a location that you deem risky, you can step up the customer and ask them for an additional factor as an additional step of verification.
3) Redirect Registration/Authentication - the ability to redirect any customer registration or authentication to a URL of your choosing if the customer is in a specific country/state/city.
4) Deny Registration/Authentication - the ability to deny any customer registration or authentication from from a location that you deem risky.
Fusion's improbable travel detection combines time/date information with a customers past and current location to perform a travel velocity calculation - put simply 'could a customer have traveled from point A to point B within the period of time between logins? If 'yes' then the login may be legitimate. If 'no' then the login is suspicious and some action should be taken.
Why is this useful? This is a signal to determine whether account take over has occurred, i.e. the legitimate owners account credentials have been stolen.This helps detect and protect against account take over without compromising a customers log in experience, but works to deny access to an attacker that may have attempted to compromise a customers account.
With improbable travel detection you can:
1) Step-up Authentication - if multi-factor authentication is enabled and an existing customer logs in from a location and the likelihood of that distance traveled from the last location seems low, you can step up the customer and ask them for an additional factor as an additional step of verification.
2) Deny Authentication - if an existing customer logs in in from a location and the likelihood of that distance traveled seems low, you can simply deny the authentication request.
3) Define Maximum Travel Velocity - define your organization's own tolerance for risk by using a velocity speed of your choosing in MPH, KPH, or Mach(!)
Fusion's geofencing provides a comprehensive way of enforcing a virtual perimeter that represents a geographic area that can be used to restrict registration and logins from inside or outside of the regions that you designate. Fusion can enforce geofencing in two ways - the first is a radius around the point of a specific geographic location and the second is as a set of boundaries (a square) around a specific geographic location.
Why is this useful? You can ensure that the customers registering or authenticating to your application or website can only do so if they're within a boundary that you designate. For instance, if you only wanted an application to be used on campus or at a particular site then this can enable you to do that.
With geofencing you can:
1) Allow Registration/Authentication from inside or outside a fence - the ability to define an allowed boundary that a customer can self-register from or log in from.
2) Step-up Authentication - if a log in occurs from inside or outside a fence - you can step up the customer and ask them for an additional factor as an additional step of verification.
3) Deny Registration/Authentication -from inside or outside a fence - the ability to define an disallowed boundary that a customer cannot self-register from or log in from.
Fusion's known device detection uses device recognition techniques and a browser cookie to remember a known device upon a successful authentication using Adaptive MFA.
Once a user has been verified and the cookie stored then they will not be asked to provide another Multi-factor Authentication method until:
1) The known device lifetime (default is 30 days and can be configured in the Adaptive MFA policy) expires because the customer has not logged in
2) Other risk is detected via any of Fusions other risk analysis techniques. In this situation, the existing known device cookie is destroyed when the customer is stepped up
This approach helps ensure a good balance of customer experience and risk analysis. Fusion will only prompt the customer again for an Multi-factor Authentication method when absolulty needed - avoiding adding any additional friction unless needed.
Fusion provides a Breached Password service that can perform risk analysis against a customer password. This helps protect against:
1) Credential Stuffing Attacks - in the event that a customer is trying to use/re-use a password with their same identifier where that password has been previously breached, Breached Password Detection will prevent them from re-using that password and will disallow that breached password from being used.
2) Account Take Over - in the event that a customer's identifier and password are part of a known breached corpus, Breached Password Detection will prevent them from re-using that password and will disallow that breached password from being used.
Breached Password Detection's analysis of customer password occurs at any of the following points in the account lifecycle:
1) During customer registration (customer attempts to provide a previously breached password)
2) During a password reset (customer attempts to re-use a previously breached password)
3) During a customer password change (customer attempts to re-use a previously breached password)
4) During an administrative password reset or change (via the Admin Console)
