If every year is The Year of PKI, then when exactly was The Year of Two-Factor Authentication? Was it 2012, when the epic hacking of Mat Honan highlighted just how vulnerable all of our digital lives are? Was it 2014, when the even higher profile iCloud leaks of celebrity photos pushed various consumer services to hastily make two factor authentication an option available to users? Or did it really arrive in 2018, at least for financial institutions, when PSD2 delivered a regulation with some real teeth?

The Struggle is Real

Two-factor authentication (or 2FA as the cool kids call it) isn’t really new. We’ve all experienced it during the course of our professional lives, but organizations still struggle with rolling out 2FA to customers. Why? The simple reason is that while employees are a captive audience that will submit to whatever painful, inconvenient mechanism you force them to adopt (ok, except for MDM on their personal phones), customers are a whole different ballgame. The customer experience matters, and if you don’t do it right then people are either going to not enable it (when you make it optional), work their way around it, or not engage at all.

For any organization starting down the path of implementing 2FA, it can be confusing and challenging. They find a large list of factors spread across the “something you ___” categories, but little guidance on how to put a good 2FA scheme in place. Most organizations simply end up taking the approach of picking an additional factor that they can simply tack on to the end of their password authentication step, and call it a day. Unfortunately, that simplified approach falls far short of successfully addressing the problem.

A Framework for Designing Your 2FA Schema

I first started going down the 2FA rabbit hole when I wrote a blog post analyzing the Mat Honan hack. Since then, I’ve had the benefit/privilege/misfortune (which one it is depends on the kind of day I’m having) of having worked on strong authentication models quite a few times. More recently in my current role at Uniken, our efforts to create a multifactor authentication model that is focused on the customer experience, and can work across industries for both small and large organizations, user bases and threat models, has yielded some deep insights into what works and what doesn’t when it comes to 2FA. The effort to distill these learnings into something that can be explained to our product team and our customers has resulted in a basic framework for how organizations should go about implementing 2FA for their customers, built on 6 pillars.

Viability

The first pillar of that framework is Viability. When going through the long list of factors possible, you have to assess which of those factors is viable for your 2FA scheme. Assessing viability has multiple considerations:

• You have to think of the people that make up your user base, and what factors they’d be willing to accept and use.
• You also have to think about the cost of the factor, and whether that is a cost that the business will bear, or the customer will bear. Hardware tokens are great, but expensive. Is the business buying it for their customers, or are they expecting the customer to buy it themselves?
• You have to carefully consider the threat model associated with the factor. The Yubikey is a really secure authentication factor, where the user has to plug the key into a port on their desktop in order to authenticate. But research studies have shown that people will often leave them plugged into their desktop even when they leave the office, virtually negating its assurance as a possession factor.You have to think of the people that make up your user base, and what factors they’d be willing to accept and use.
• You also have to think about the cost of the factor, and whether that is a cost that the business will bear, or the customer will bear. Hardware tokens are great, but expensive. Is the business buying it for their customers, or are they expecting the customer to buy it themselves?
• You obviously have to consider the effectiveness of the factor. See: security questions.
• In many cases, regulatory compliance can enter the equation, since regulators are increasingly rendering opinions on which factors are acceptable for your business.

Multimodal

The second pillar of the framework is Multimodal. When implementing two-factor authentication, the goal is to have each user employ at least two factors when authenticating (obviously). However, that does not mean that the business is only going to support two factors. Not all factors work for all users, and when you’re trying to increase the number of customers turning on 2FA, you have to offer options that work with your vast and diverse user base. The idea that you can find two factors that work for everyone leads you to a least common denominator approach, and that’s how we got SMS OTP as the de facto “standard” in 2FA, and a weakening of the security model. Offering choice allows you to address the varying capabilities, preferences and circumstances of your end-users, and avoid a “one size fits all” approach that alienates customers and often weakens your security.

Adoption

I’ve alluded to the third pillar, which is the one that is the most misunderstood – Adoption. The reality is that unlike enterprise environments where you can mandate 2FA, the customer environment requires you to actually convince your end-users to start using 2FA. There’s a wonderful research paper called “Why Johnny Doesn’t Use Two Factor” that I highly encourage everyone to read. While there are many important takeaways in the paper, one overarching lesson from the paper is that organizations need to make UX research a core element of their IAM program, especially as they design their 2FA scheme. It’s a critical and foundational element to creating the right set of messaging, training, and incentive components that you will have to incorporate into your roll out plan to drive adoption.

Omnichannel

An overlooked pillar is Omnichannel. Businesses have often failed to recognize that 2FA shouldn’t apply just to their web or mobile channels, but must be deployed across all their customer facing channels. Businesses are engaging with customers and partners across many channels – web, mobile, call center, in-person, chat, smart home assistants, and more – and each channel usually brings a completely different way of authenticating the end-user. That inconsistency frustrates your end-users, creates a headache for your customer-facing staff and IT staff, and delights bad actors. Attackers look for the weakest link across those channels, and go after that one, exploiting not only the weakness of the channel, but also the frustration that your customers and employees feel. The result is rampant account takeover attacks and fraud. Businesses have an imperative to transition away from an inconsistent hodge-podge of varying  authentication models, and bring some consistency and equality of security levels across their various channels.

Processes

The fifth pillar of the framework is the one that most organizations don’t pay enough attention to  – Processes. Enabling and maintaining 2FA for individual customers involves many different processes, each of which needs to be properly designed:

• Enrollment: If the enrollment process is flawed, the assurance of your 2FA is suspect from the very beginning. Many organizations will allow users to set up their second factor after they’ve authenticated solely using their first, and that is a massive vulnerability point in your scheme.
• Backup: No authentication factor is immune from loss or destruction, so you have to think about ways to not only allow, but proactively encourage, your customers to set up additional authenticators as backups. And those backups better have the same strength as the primary, otherwise you’re creating a backdoor for attackers.
• Escape Paths: Not all authentication factors are always available for use. Consider what happens to push notification based authentication for someone working in a part of the building, or on a plane, where they get no signal. Locking them out under those circumstances can be hugely problematic.
• Recovery: Consider how you will support an end-user that has lost their authentication factor(s), so that they aren’t faced with the dire consequence of being permanently locked out (think of all the horror stories of bitcoin wallets irrecoverably locked up because their owner lost the hardware token containing their private key). Recovery paths must also be designed properly to avoid having them turn into backdoors for bad actors. And for heaven’s sake, never use an authentication factor as the verification factor for also doing recovery. I’m looking at every service that uses SMS OTP as a second factor of authentication, and also as a way of resetting a forgotten password. You’ve effectively created a backdoor that turns your two factor authentication scheme into a one factor authentication scheme.
• Deprovisioning: Of course, you have to consider how one can go about invalidating a factor that is no longer available to the customer, or is no longer acceptable to the business because of vulnerabilities or issues discovered in it (whether it be at an individual level or system wide).

Importantly, escape paths and recovery flows need to be treated as exceptions with higher risks associated with them. That often implies increasing the risk evaluation and security of those flows, which often means adding friction. However, customers are frequently understanding of the increased scrutiny in those paths (provided you’re explaining it to them).

Trusted Environment

The sixth and final pillar of the framework is establishing a Trusted Environment within which to execute 2FA. It won’t really matter how good or strong your factors of authentication are if the environment within which those factors are being accepted, stored, transmitted, and evaluated is compromised, allowing them to be stolen, manipulated or replayed. Keyloggers that capture secrets, malware apps that intercept SMS codes or steal keys, malicious WiFi, reverse proxies, and rogue cell towers that capture and replay credentials or tokens – threats like these reduce the effectiveness of 2FA and degrade organizational trust in those factors. Your two-factor authentication project has to be part of a larger security program that enforces defense-in-depth (or, to use the industry term du jour, zero trust security) to not only leverage the factors of authentication, but also look at the health of the devices and hardware being used and the networks being relied upon, as well as other signals of risk, in order to build trust in (hopefully) the simple act of authenticating your customer.

So, there you have it. A simple framework to apply while designing, building and rolling out your two-factor authentication program. May all your authentications be strong, and all your customers be happy, engaged and protected.

[This article is adapted from my talk at EIC, Identiverse and Identity Week. You can watch the Identiverse talk here.]

Nishant Kaushik
CTO, Uniken Inc.