We have already explored some common best practices in step-up MFA, including: risk analysis, choice of authentication factors, privacy, lock-out, registration, which we will discuss today. Other best practices also include: user opt-in, suspension and bypass, self-service, native applications, initial authentication and multiple touch points/channels.
Different user constituencies may make it impractical to mandate step-up MFA for all users. Someusers may not have a phone capable of supporting mobile app-based authentication. Some users maybe apprehensive of and slow to adopt new technology. Step-up MFA should be marketed as a meansto protect customer data rather a company’s information assets.Educating customers on the value of MFA is important. Creating opt-in incentives may be moreeffective. Some customers may be convinced to opt into MFA through offers of enhanced services.For instance, a U.S. bank increases the daily and weekly transfer limits for customers who sign up for its MFA service. Google offers a bonus to users who opt in to step-up MFA through a security checkup. As for the enterprise, where MFA may be mandatory, allow for a graduated transition, where employees can choose to defer registering for MFA a few times or for a short period.
Suspension and Bypass
Develop secure and thorough exception processes and backup access methods for common user situations such as forgotten, lost and stolen MFA credentials. Consider allowing users to opt out of step-up MFA if they’re accessing the application from a known and trusted device from which they’vepreviously performed the MFA step successfully. Or you can apply a risk-based approach to a trusted device model and not require users to explicitly opt out. Google uses this trusted device model to minimise overt step-up prompts. For lost or stolen devices, implement a process that allows users tosecurely access the application or register a new device.
Possible recovery mechanisms include:
• Sending a reset email to the registered address
• Knowledge-based answers (KBA)
• Printed recovery codes (which presumes users will safely store these and remember their location)
Non-secure recovery processes include asking questions that can easily be answered with a few Google or Facebook searches—for instance, where did you go to school?
Giving users the ability to manage their MFA mechanisms and devices themselves can provide important efficiencies. Self-service
MFA mechanisms can be relevant at times of enrollment, recovery and revocation, and can minimize the need for costly administrative
interventions. Self-service mechanisms can also give users more control over and visibility into their authentication information, which can enhance privacy overall.
The best practice for authenticating users of native applications is to use OAuth 2.0 or OpenID Connect 1.0. When the native app is first installed (or at some frequency after installation) the native application launches a browser window (not a web view) and loads the sign-on page at the corresponding server. After authentication, tokens are delivered back to the native app for subsequent use on calls to the relevant API. At the time the token is issued, the provider may choose to enforce MFA. Based on the nature of the native application, policy may dictate that MFA is required even at the initial installation and setup. Because the authentication should happen in a browser window, and not within the application’s UI, the same sign-on page (and step-up policy and architecture) put in place for the normal web application can be leveraged.
Through what are called “refresh tokens,” OAuth allows for a long-lived session for native applications. This means that users may not be asked for an explicit sign-on for long periods of time. If long-lived refresh tokens are used, adding MFA to the sign-on process can help to more tightly bind that native application to the valid user, which can minimize the risk of the long-lived tokens. It’s also possible to implement a step-up MFA model for native applications. When the application presents a token on a request to a particular function, the API can assess the LoA associated with that token and, if insufficient, deny the request and indicate back to the application that a new token (with higher LoA) is required. The application passes this requirement back to the sign-on page, which triggers the appropriate step-up flow. Additionally, the API can collect similar contextual information (e.g., IP address, time of day, app behavior) and feed that into the risk engine.
While MFA mitigates some of their security issues, passwords are likely to remain the default first factor—the initial credential the user presents to the authentication server—for the foreseeable future. Current UX design typically prompts users to provide both on the same screen. In the future, however, it may not be a password that the authentication server asks for as the initial credential. Instead, context or some other mechanism may be sufficient, which would negate the need for a password. It may make sense for organizations to consider a UX design that anticipates this future. Google is doing just that. Google separated the request for username and password from its sign-on page in May 2015. Distinguishing between how users identify themselves to Google and how they authenticate creates greater flexibility for future authentication schemes. When Google rolls out novel authentication methods beyond passwords, the first identification page won’t need to change. Additionally, authentication logic sitting behind the first page can choose the appropriate authentication method for a given combination of user and context.
Multiple Touch Points / Channels
If a company offers multiple channels by which its customers can interact with application resources and data—for example, web, mobile apps,telephony and brick-and-mortar locations—the MFA choice may be different for different channels. For example, a U.S. bank uses passive voice biometric authentication for its telephony channel. Similarly, Canadian bank Manulife recently announced an update to its interactive voice response (IVR) system with the deployment of natural language understanding (NLU) and passive voice biometric technologies.
It is clear that enterprises must continue to evolve and improve their authentication of users, moving beyond the limitations of passwords and traditional 2FA. MFA is better, but using contextual data to dynamically step-up authentication is the right approach for enterprises.