Doing 2FA Correctly Requires More Than 2 Factors

Two Factor Authentication (or 2FA) has been in the news a lot recently. There was the kerfuffle over NIST putting into their update of 800-63 that SMS-based 2FA is insufficiently secure and should be deprecated (something most security experts agree on). That update (still in draft) came too late for the Social Security Administration (SSA), which announced at pretty much the same time that they were making SMS-based 2FA mandatory for access to their my Social Security online service. And while it didn’t receive as much play, there was this tiny issue that surfaced showing how the lack of 2FA for the ‘Find My Phone’ feature of iCloud (which does have 2FA) creates a vulnerability that can allow a hacker to locate a person and wipe their devices (iPhones, iPads, Macs).

A common theme that I see across these discussions is a misunderstanding of what it takes to properly implement two-factor authentication (or Multi-Factor Authentication, for that matter). It isn’t as simple as taking your username/password based authentication and just adding a second factor to it over the weekend. I’ve seen too many projects do just that – add a second factor like SMS-based 2FA, add a cookie based mechanism to remember that 2FA was done so as to not ask for it each time, and call it a day. Doing it properly requires a little more thought.

One of the reasons why username/password became the de facto standard in authentication, and why it isn’t going away any time soon, is that it is nearly universally applicable (though that universal applicability is also what makes it extremely vulnerable and weak as your first factor). So pragmatically speaking, this discussion becomes all about that second factor. And that’s why doing 2FA correctly requires understanding context and being adaptable. In other words:

• Understand your risks
• Understand your audience
• Support alternate factors and flows

Understand Your Risks

To most of us in the identity and security world, this goes without saying. But it bears repeating since often times discussions about 2FA seem to forget this part. What vulnerabilities does a certain second factor have, and how much effort does it take an attacker to compromise it? And how much damage can be done by compromising one users second factor (aka: how worthwhile is it for the attacher to make the effort)? Discussing bank accounts and corporate email is easy. But are Twitter and Opentable comparable? Hacking someone’s Opentable account probably isn’t worth the effort it takes to hijack someones phone number. But in a world where a hacked tweet from an account like the Associated Press can move markets, hacking the iCloud accounts of celebrities can violate privacy in a very public way, or compromising a prominent activist like Deray can influence the socio-political landscape, a phone hijack is well worth the effort in a targeted attack.

And while I love authenticator apps, it’s important to understand how strong the users authentication to the authenticator app itself is protected. As I explained in my analysis of the Mat Honan hack, understanding the root of your authentication chain and how vulnerable it may be is critical.

Understand Your Audience

One of the reasons why SMS-based 2FA seemed to become the de facto second factor in the rush to 2FA All The Things was because it shares that near universal applicability characteristic of username/passwords. All the user needs is a mobile number capable of receiving text messages, unlike authenticator apps which require smartphones, or physical solutions like Yubikey that require the user buy and carry something. It’s an important characteristic, and one of the reasons why there seems to be a rush towards voice biometrics [1, 2, 3, 4] (as opposed to fingerprint or facial biometrics that require smartphones). But security shouldn’t be a least common denominator approach. Yes, it’s a lot easier to impose requirements on the user base in an enterprise context (everyone must carry a SecurID token) than in a consumer context. But it isn’t impossible if you’ve actually done the work to analyze your user demographics, their willingness to tolerate pain in your service context in exchange for security (banking vs shopping, for instance), and the requirements imposed by your service (for instance if your service can only be accessed by smartphone users).

Support Alternate Factors and Flows

If you have a good understanding of your services context, then you can enhance 2FA by making it adaptable. Remember, adaptable means “able to adjust to new conditions”. And while the term adaptive authentication has definitely come to encompass the stepping up of authentication in response to new conditions (elevated risk), we seem to have forgotten the other requirement of switching to alternate flows in response to new conditions (different circumstances). 2FA is great when everything is as it should be. But like any good product manager will ask their teams – what of the exception use cases? If your second factor requires on the user having access to their mobile phone, what happens when they lose it? Have you thought through the flow when the user switches from one phone to another? Or what if the second factor simply isn’t working?

Get Busy Creating Authentication Flowcharts

Your authentication process needs to be able to leverage both the identity and state information (stored context) as well as the user input (live context) to direct the user down the appropriate two-factor or multi-factor authentication path at any given time (adaptability). This means identifying all the possible and applicable second factors and tying them all together through appropriate primary and exception flows. If it sounds like a lot of work, it is. Which is why finding a good authentication framework or service can save you from a world of hurt.

Putting Context and Adaptive into Action

• The “Find My Phone” use case seems to have taken the approach of assuming that the phone is the second factor and so it will only get used when the phone is inaccessible (lost), so it just drops the second factor (becoming one factor). First of all, why make that assumption when there are other devices in the list that could be lost? And second, why not have a alternate factor to use specifically in this use case? As the article points out, why not identify the device the user has logged into iCloud from, and if they are on a registered device, then accept it. Otherwise use a more painful, but in this case necessary, alternate second factor. I absolutely abhor security questions, but this is a use case where they could be useful. Or a voice biometric stored in iCloud that is set up at the time of setting up “Find My Phone”. The critical thing here would be to remember that it cannot be something that a person who has stolen and compromised the phone would have access to, like email.
• Adaptability can also mean switching factors depending on context. The Twitter use case is an interesting one. For the vast majority of users of Twitter, SMS-based 2FA is actually good enough. But Twitter should first of all give users that want it a choice of having a stronger second factor like an authenticator app. And secondly, they could force a stronger second factor on certain users based on context they know about that user’s elevated risk – whether they are verified or not, how many followers they have, etc. But even with that, they would need an alternate flow to handle the “I don’t have my phone” scenario. Keep in mind that this can’t rely on the email channel (same reason as above). But I’ll get to that in a bit.
• The SSA use case is similar to Twitter’s in one sense. Lets leave aside the fact that adding SMS-based 2FA doesn’t address their actual security issue, which is an identity verification problem in the registration process that has fraudsters using data obtained from underground markets to create accounts for citizens that don’t already have accounts and claiming their refunds. Just like with Twitter, SMS-based 2FA is actually a good enough second factor for the vast majority of citizens from a security standpoint, because it isn’t worth the effort of hijacking their mobile numbers for the limited haul per account. Unlike Twitter however, the SSA has to think of the entire citizenry from a demographic standpoint, and so the SMS-based model is facing some backlash because it locks out people who have no mobile phones, like senior citizens. Having multiple layers to fall back through (which could include partnerships with entities like banks and the post office) that are tied to the underlying identity model make this a very complex project to solve.

Ultimately, doing two-factor authentication properly requires having more than just two factors as part of your approach, and using context to help pick the right combination of two factors to use at any given time. And if you can supplement this with additional passive factors (like device recognition and behavioral analytics) to convert it into a multi-factor model, then all the better.

Thinking through all this for the purpose of this post has also brought another interesting thought to my mind, but I think I’ll keep that for my next post (hopefully it won’t take another few months for me to get around to it). It’ll also address the question I left dangling in my discussion of the Twitter use case above. So stay tuned.