Organizations have many different ways of implementing multi-factor authentication (MFA). In particular, some organizations have reused preexisting authentication mechanisms such as Active Directory in their MFA implementation, some have not. However, the applications protected by MFA or the devices used for MFA can’t really explain the variety of MFA implementations. What is it then? History? Geography? Random? More importantly than the reason, what are the benefits and implications of the various approaches?
2-step verification, 2-factor authentication
MFA is a form of authentication where a user proves her identity online with a combination of something she knows (a PIN or password), something she owns (a long digital key stored in a hardware device or in a smartphone App, and by extension, a messaging address attached to a device, such as a phone number), and something she is (a biometric trait). In reality, MFA is mostly 2FA, also referred as “2 factors”. However, organizations have very different ideas of MFA.
For some, the second factor is something asked to a user after a primary authentication – the usual username & password combination. The second factor in this case is associated with a device or, less frequently, with a biometric factor. This second factor verification is often referred as step-up, and the whole process as 2-step verification or 2SV. But most people just call it 2FA.
In contrast, other organizations implement MFA in a way where both factors are asked simultaneously and verified simultaneously. This 1-step version is simply referred as 2FA.
2FA? Oh, you mean 2FA?
So when I hear someone say that they have implemented 2FA or intend to implement 2FA, unless I already know more about the context, I can’t decide whether it’s ‘true’ 2FA or 2SV. People with similar job titles in different organizations use the same word for different things.
Maybe 2SV is a more recent approach, initiated with SMS-OTP in consumer-facing applications, as opposed to an older approach, Enterprise-born and security-driven. Maybe 2SV is more popular in North America whereas European companies favor 2FA (for Asia, I don’t have a clue).
Or maybe not. I got used to it. But does it really matter, and why?
Differences, benefits, and implications
Unlike password-based authentication, MFA is something that you need to add to a network or application. Whether it’s open-source and / or developed by a vendor, MFA is an add-on, a solution. A solution that needs to be integrated, provisioned, operated, and so on.
When implemented as 2SV, an MFA solution handles the second factor only – usually, something I have – in which case the organization implementing MFA manages the first factor – usually, something I know, a password. When implemented as ‘true’ 2FA, an MFA solution handles both factors. This simple difference has 2 consequences that partly explain why organizations make different implementation choices.
First, with 2SV, the step-up verification can be triggered conditionally. MFA has the reputation of being “complex for users”. Therefore, some organizations implement it in a way where they deactivate the step-up verification for transactions that they think have a low risk, which is possible with 2SV, not with ‘true’ 2FA. However, as discussed in a previous post, modern 2FA comes with a lower friction than password-based authentication, so choosing 2SV over 2FA for that reason doesn’t make much sense any longer.
Also, some solutions, even when they are implemented in a 2FA mode (solutions such as inWebo support both 2SV and 2FA), can deactivate the second factor request on a transaction basis, for instance when it’s not necessary to ask the user to enter again her password. The boundary between 2SV and 2FA – that the former offers more flexibility than the latter – has therefore become blurred.
Second, ‘true’ 2FA introduces a new user secret, whereas 2SV uses an existing one, usually the Active Directory password in IT organizations, or simply the user password in services like online and mobile banking. This means that the networks and applications that are protected with 2SV must be federated with AD or the existing authentication database. When it’s not the case, it’s easier to implement ‘true’ 2FA, which is probably the reason why it is often employed for VPN authentication.
Why NIST says NO to SMS-OTP – and what it means for 2SV
In guidelines released end of July 2016 (link), NIST bans 2SV based on SMS for the reason that it’s hard – or even impossible – to be sure that the phone number where the OTP is sent is really attached to a hardware protected device, and therefore it can’t be considered as a something I own factor. Attacks to bypass SMS-based 2SV have been massive from day one, from social attacks (calling the bank with enough information about you to have them change the phone number associated with your account), to malwares (silently forwarding OTP to wherever needed by the attacker), to SS7 hacks (intercepting or forwarding texts).
The appeal of 2SV was great: based on messaging or call-back, 2SV assumes very little about users, only that they have a phone or a separate channel such as email where they can be reached. That level of assumption was reasonable in the early 2010s when banks deployed SMS-based authentication for sensitive transactions and card-not-present payments. 5 years later, smartphones and html5 have generalized, enabling robust frictionless App-based and browser-based 2FA (both 2SV and ‘true’ 2FA) for everyone. Security, reliability, and convenience have never been a strong argument for SMS-based authentication, but costs were, at least when the competition was hardware tokens. But even this reason has disappeared. With no more rationale and with more government agencies banning SMS-OTP, the days of ‘App-less’ 2SV are counted.
What will replace it?
App-based authentication, out-of-band (e.g. with push notifications) or on-demand is a safer form of authentication since the something I own is now attached to a device. The problem with existing standards such as TOTP or HOTP though, is that the link with a device is still weak since the key can be extracted and copied, particularly in a software 2SV implementation where that key cannot be seriously encrypted, but also in most software implementations of ’true’ 2FA (inWebo has something special here, I know that because I designed it). Hardware-enforced gestures (FIDO or not) and TEE (Trusted Execution Environment) will progressively improve the security of the link with the device. For the rest, App-based authentication is already a cost-effective, convenient, and widely available replacement for user 2FA in all segments.
Given the generalization of html5 that enabled it, and the fact that most access requests come from known user devices, I also suggest that browser-based authentication is a serious challenger (see another recent post).
No definitive winner
While it’s clear that App-less 2SV will leave the way open for App- and browser-based 2FA, there are no indications that 2SV might impose itself against ‘true’ 2FA, or vice versa. Strong arguments for one or the other form progressively disappear as organizations implement SSO (therefore federating most applications and networks protected by 2FA) and find ways to not expose AD credentials (such as LDAP proxies).
Yet, consumer-facing applications using 2FA have probably ‘biased’ the market towards 2SV when it was the only available or affordable solution. Although the rationale has disappeared, the bias will probably stick.