Two-factor authentication (2FA) versus two-step verification (2SV)

What’s the difference between 2FA and 2SV? And which is better?

Authentication key

As we go about our online lives, many of us have considered enabling two-factor authentication (2FA) or two-step verification (2SV) on our accounts. Both measures introduce another element into a service's login process. For that reason, plenty of reputable sources online have left the impression that there is no difference between the two concepts.

But those reports are wrong.

In this article, I will put to rest the difference between 2FA and 2SV.

What is an authentication factor?

Before we explore the difference between 2FA and 2SV, it is important to first touch upon what happens when we sign into an account.

Each login process depends upon the user submitting an authentication factor, or as SearchSecurity puts it, an "independent category of credential used for identity verification."

Authentication factors come in three different types: knowledge factors ("something you know"), possession factors ("something you have"), and inherence factors ("something you are").

The weakness of the password

Most online accounts today are configured to support single-factor authentication (SFA) by default. Those accounts more often than not require that a user submit a knowledge factor in the form of a password.

Login form

By now, we're all familiar with how inadequate passwords can be for protecting our accounts.

This insecurity rests with the demands of robust password security: first, users must accept the onus of creating long, complex passwords that are unique for each of their accounts; and second, they must either commit those passwords to memory or store them somewhere safe; and third, if a site is compromised they need to change their passwords to similarly long, complex combination.

All these steps have certain costs.

Humans are notoriously bad at dreaming up passwords that are sufficiently strong and hard to crack. Fortunately, some password managers such as Dashlane, LastPass and 1Password have the ability to generate strong passwords for a user.

Humans typically find that "secure" passwords are difficult to remember and take time to manually enter character-by-character on a keyboard. To respond to that difficulty, there are now a number of password managers that store and auto-fill users' complex passwords via browser extensions. However, many of these services require a paid subscription - something in which some users might not want to invest.

Finally, changing passwords after a security scare is a time-consuming burden. Usually is not an automatic process, although some password managers are beginning to offer such functionality on a growing but nevertheless select list of sites.

For all of these reasons, users may choose to skimp on their password security. Web services recognize this tendency. Some have opted for more secure forms of SFA, such as biometrics. Others have responded by implementing 2FA or 2SV. A select few have done both.

2SV: An expansion of SFA

Two-step verification is perhaps the easiest way by which web services can respond to the costs of password-based SFA. A common manifestation of this feature (if activated on an account) proceeds as follows: when you enter in your username and password, you are then sent a one-time code via email, SMS, or phone call to your computer or pre-verified device. You must enter in that code within a specified amount of time in order to access your account. If you don't, the code expires, and you will need to have another code sent to you.

Two step verification

As a user called "tyler1" notes in a discussion forum on StackExchange, this method of signing in may at first appear to be two-factor authentication.

But it isn't.

Even though you yourself do not know the code beforehand, the code is not fundamentally different from the password. In fact, they belong to the same authentication factor: both are pieces of information, that is, "something you know."

With this in mind, two-step (or multi-step) verification simply expands SFA by requiring that the user submit several distinct verification occurrences that all fall under the same one of the three authentication factors discussed above.

And, as we have seen in recent malware attacks, it is becoming for malware to intercept a two-step verification tokens as it is transmitted to the user and share them with criminals.

2FA: A whole new ballgame

By now, you might have an idea as to how two-factor authentication differs from 2SV.

Rather than building upon SFA, 2FA requires that a user enter two distinct verification occurrences that each belong to their own separate category of credentials. This may take the form of a user entering a password ("something you know") followed by depressing their thumb on a fingerprint scanner ("something you are").

It may also consist of the stuff of spy thrillers: someone swipes their keycard in a door-locking mechanism ("something you have") and then has their irises verified by an eye scanner ("something you are").

Smart cards and Yubikeys further add to the list of possible 2FA combinations.

Quintessentially, two-factor authentication hinges on the reality that it is more difficult for an attacker to compromise two authentication factors rather than just one, such as the knowledge that is required for someone to enter their password and a generated SMS code. With that in mind, it is reasonable to say that when implemented properly, 2FA is more secure than 2SV in-so-far as it introduces an additional factor of authentication.

Conclusion

There you have it. While two-step verification merely expands SFA by requiring two distinct verification occurrences of one authentication factor, two-factor authentication requires two occurrences that each falls under a different different category of credential.

Now that we know understand the difference between 2FA and 2SV, it's important that we see both them in action. Towards that end, below you will find links to a series of articles explaining how to enable two-step verification on different accounts.

Tags: , , ,

Subscribe to the free GCHQ newsletter

, , ,

Leave a reply

28 Comments on "Two-factor authentication (2FA) versus two-step verification (2SV)"

Notify of
avatar

Sort by:   newest | oldest | most voted
Paul Moore
Visitor
Paul Moore
March 14, 2016 3:46 pm

Here's a flow diagram with supporting information.
https://paul.reviews/the-difference-between-two-factor-and-two-step-authentication/

David Bisson
Visitor
David Bisson
March 14, 2016 9:21 pm

Extremely helpful and detailed resource. Thanks for sharing, Paul!

Xand
Visitor
Xand
March 14, 2016 6:40 pm

Would Google Authenticator and similar apps count as 2FA or 2SV? They require a secret token (seed) to be sent to the user from the online service initially, but from then on, there is nothing for criminals to intercept. They then function as would a hardware-based one-time-token device, though depending on implementation, it may be possible to extract the seed. Thus changing them from "something you have" to "something you know".

David Bisson
Visitor
David Bisson
March 14, 2016 9:15 pm

Stay tuned, Xand. I'm covering Google Authenticator in an upcoming post. All will be revealed.

Randy Harris
Visitor
Randy Harris
March 14, 2016 8:58 pm

Thanks, David, for the excellent explanation of the difference between 2FA and 2SV authentication. You managed to make it something that even I understand.

David Bisson
Visitor
David Bisson
March 14, 2016 9:15 pm

My pleasure, Randy! Glad I could help clarify the discussion.

Roger
Visitor
Roger
March 14, 2016 9:54 pm

In your example of 2SV of using password and sms code, they are 2FA: password is what you know, sms is what you have (sending to your mobile, not others).

Bob
Visitor
Bob
March 15, 2016 1:20 pm

You're wrong.

A password and SMS are both steps and not factors. I explain it in more detail in a post lower down.

Password + SMS Code = 2SV
Password + Smartcard = 2FV

Kelly
Visitor
Kelly
April 6, 2016 1:35 pm

Essentially, the SMS code sent to the user is designed as a linkage to inform the Service Provider that the user is indeed in possession of the device that received the SMS code. Entering the SMS code is clearly something you know, but it gives evidence that the user is in possession of something they have. In addition, the definition of "something you know" is understood to be something you know before-hand, (i.e. before the transaction), which in the case of a properly designed multi-factor solution, is not known before the initiation of the transaction.

I would add to the discussion, that it is becoming increasingly important that service providers be moving to evaluate many factors in connection with transactions, and not just the login, but post login. These factors include: Local Device AuthN, Device HW, Location, One-Time-Keys, Behavior, Application Thresholds, IoT Hardware Tokens, User Type/Authorization Rights (Admin/Consumer, etc.) Transaction Risk, Time, IP, ISP, Jail-Broken, biometrics/kinetics, and device-certificates.

Alignment of many factors (that change all the time at different rates I might add), create an extremely challenging and dynamic puzzle for a hacker to navigate while the factors are changing in mid-stream.

Challenging the user when things don't line up, then becomes the next step. Biometrics are great (unless they are stolen as in the case of the US Gov't hack last year), but every company I talk with wants to add more factors beyond biometrics.

Having more factors also allows service providers to invisibly authenticate users without challenges (which are in most cases a bit of a pain). It's fine to argue the definitions and implementations of 2FA & 2SV, but there is a lot more detail under the covers that is worthy of discussion as well.

My last comment, is that in general, most service provider's implementations of additional login security are Otp-In, which historically results in very low adoption (single digits). This type of security doesn't really increase assurance across the board for the service provider.

Bob
Visitor
Bob
March 14, 2016 10:01 pm

I'm glad to see this. I often see the two acronyms used interchangeably and incorrectly – naturally 2FV is the more secure but very few sites genuinely support it.

John Lewis
Visitor
John Lewis
March 15, 2016 10:16 am

Some sites ask for a mobile number for 2FV – which IMHO is not very secure at all since it is easily discovered.

Bob
Visitor
Bob
March 15, 2016 1:21 pm

That's a second step; not a second factor.

Some sites ask you for a second piece of information each time before they'll allow you to sign in (e.g. your mobile number, place of birth etc.) and others will send you a one-time code to your mobile (that's 2SV).

Brett C
Visitor
Brett C
March 15, 2016 12:14 pm

Hi, David. I get that the one-time code is something you know, just like your password. But, because it is sent to something you have (your cell phone) doesn't that someway qualify as 2FA also?

Bob
Visitor
Bob
March 15, 2016 1:10 pm

No because you don't physically 'have' the second factor. You enter your password via the keyboard and you enter your second code via the keyboard. Whilst using 2SV is more secure than just a password it isn't a true second FACTOR … it's a second STEP.

Think of this:

To get into a high-security safe you need your key (one factor) and then a combination (one factor). Those are two factors.

Now think of a safe with two combinations (instead of a key and a combination). If you know, or have access to, the second combination then you can still get in.

In the first example an attacker would need lock picks and also equipment to break the combination.

In the second example an attacker only needs equipment to break the combination. It's obvious which is more secure.

Going back to the computer example – intercepting a text message/phone call containing your 2SV code is trivial for a well-prepared attacker as there exist an abundance of ways to monitor your communications. However having a password (something you know) and a smartcard (something you have) make any attack extremely difficult.

Andras Deri
Visitor
Andras Deri
March 15, 2016 3:55 pm

I think we are mixing the theory of authentication and the present practice (implementation, realization of it).

Having a phone for receiving the code in SMS is an independent factor, a second (communication) channel (as some are calling it).

To block the provider not to give a second SIM card without proper ID (or other – known – wrong handlings) are part of the insecure implementations of these processes nowadays.

Mark Jacobs
Visitor
Mark Jacobs
March 15, 2016 12:21 pm

So, a password plus a DNA sample could be regarded as 2FV. However, if the password is known to the attacker, and they also have a sample of your hair, fingernail or whatever, then you are still screwed! You really need multiple FV, where a password, voice scan, iris scan, dna sample, stool sample, urine analysis, fingerprint, toeprint, brain neuron map, … are all required, else you cannot access your account.

Sparx
Visitor
Sparx
March 15, 2016 12:27 pm

Am I paranoid to worry about the rise in popularity of the "something you are" verifier (basically, biometrics of whatever flavour)? Because if you have a "something you know" or "something you have" stolen, you can at least replace/change it. But "something you are" can't be altered, and if it's stolen, that gives a whole (frightening) new meaning to the term 'identity theft'. We've already seen demonstrations of fake copied fingerprints that can deceive fingerprint readers, and I believe it's only a matter of time before any other form of biometric ID (however complex – instant DNA testing, anyone?) can be convincingly forged too. Basically, if it can be read, then it can be copied. We've already seen even government agencies get hacked for passwords and personal data, and I have absolutely no confidence that we won't (quite soon) see a stack of fingerprint or iris scan data on the web that got stolen from some inadequately secured organisation (or left by mistake on the train on an unencrypted hard disk by some irresponsible employee).

Karel
Visitor
Karel
March 15, 2016 1:52 pm

This scares me a lot too. If I'm being forced to giving up my password and my smartcard, I still live. But for my iris scan, fingerprint etc, they need me, personally. That means that with a bit of luck they copy my iris/fingerprint, but in less fortunate cases I loose an eye, or finger, or worse.

Sparx
Visitor
Sparx
March 15, 2016 2:44 pm

Better bio-ID readers include a liveness test – something that ensures that whatever it is reading is attached to a live subject, so removing your eyes or fingers from you wouldn't work with these – and if you just want a copy of the information (to fool a simpler reader), there are easier ways of getting it (e.g. you leave fingerprints everywhere). So I think (thankfully) your eyes and fingers are most unlikely not to remain attached to you!

My point is that (if you make the assumption that ultimately the raw bio data will be stolen in bulk – which it will) the security of the system depends solely on the hardware complexity of economically creating a forgery that works (definition of economical depends on the potential reward to the attacker). (And yes, some forgeries have overcome liveness tests). History teaches us that hardware (or system) complexity is, in the long term, a very poor security measure.

I might also add that I have serious privacy concerns anyway about the idea of this bio information being held by any organisation other than legitimate law enforcement agencies for fully and properly regulated reasons.

SteveP
Visitor
SteveP
March 15, 2016 12:32 pm

"it is becoming [?] for malware to intercept a two-step verification tokens" (needs an edit)

I've had to disable Apple's 2FA. It became so confusing – especially with a new computer install (depite using the Migration Assistant) – that it was impossible to determine which password, code, token, widget or ding-dong a dialog referred to.

Part of the problem is that Apple has multiple, confusing and conflicting uses of the word "code" and password – ideally each request for authorization would indicate what it was for and use an exact term for what was required. At one point I changed the password for one account when Apple was actually referring to another (you have to have multiple iTunes accounts to access different "stores" in different countries. Apple makes this possible, but cumbersome. Google makes this almost impossible – they can't understand a multinational user at all).

Apple offers to send a "verification code" to a registered device, but these often don't arrive in a timely manner (or at all) meanwhile iCloud is asking for a password/auth, plus iTunes, FaceTime, iMessage….

I had to turn it off. Perhaps they will figure it out in a future world

And it is interesting how well some 2-steps work (Authenticator for Google and Dropbox works fine, but still has the issue that I use three different phones for different national accounts, but can only run Authenticator on one – there could be a "synched" version across multiple devices).

PayPal US uses a "secure ID" number-generated token, but PayPal UK uses a sent sms token. Try and use the iOS PayPal app and pay for a UK purchase and it asks for a token from a Secure ID style token, even though none is associated with that account, and the phone # that is associated is the one running the app. So if you are on a laptop, the sms token comes to your phone, but if you use the mobile app on the same phone, you can't get the sms even sent. (You can complete a US PayPal purchase on mobile.)

These people are at the top of their game? That's the scary part

Pocono Chuck
Visitor
Pocono Chuck
March 15, 2016 1:58 pm

An additional problem with SMS codes for a 2SV is the habit most people have in that their SMS messages are shown on the lock screen of their device.

First, too many people don't even lock their device; those that do, and allow their SMS to be displayed on the lock, run the risk of their device being stolen by the hacker who has, perhaps, somehow discovered their password.

Sure, it's inconvenient to unlock a phone every time you want your 2SV code, but that means its inconvenient for the bad guys, too.

Bob
Visitor
Bob
March 15, 2016 7:09 pm

Realistically though that's an issue most people won't encounter.

2SV is great for protecting you from hackers but if somebody has physical access to your phone then it's game over anywhere. The SIM can be removed from the device and put into another device (or even a computer) and the SIM PIN bypassed with ease.

2SV gives a good level of protection against phishing attacks (assuming the user doesn't give out their 2SV code), protects them from a snooping third-party gaining access to their account and means that you can login to secure websites from a work computer and your employer won't be able to login themselves (obviously they could monitor you in real time).

Disabling SMS at the lock screen is an inconvenience for many users although will add a little protection against 'rogue' family members. It won't stop a determined attacker who has access to your device.

Jeremy
Visitor
Jeremy
March 29, 2016 3:45 am

While I get what you're saying, I disagree with your generalization that all phones can be compromised simply by swapping SIM cards. If you were familiar with the CDMA cellular system in use by Verizon, Sprint, and other US providers, you'd know a SIM isn't required for simply making and taking phone calls, nor for sending and receiving SMS messages. Furthermore, I would challenge the notion that a time/algo based code doesn't meet the requirements to be considered a "true" second factor. Google Auth, for instance, works independently of a network connection, and aside from the initial setup that requires scanning a barcode or typing a passcode string secret, is not subject to being intercepted by a malicious third party. Note that in this case I'm referring to the protection afforded by using Google Authenticator as a second-factor; not the Gmail service which contains a weakened implementation of said second-factor for the sake of convenience, as in the event of a lost/broken/misplaced code generator, one can opt to have the requisite passcode sent via SMS to a (potentially compromised) phone instead.

richard
Visitor
richard
March 15, 2016 5:37 pm

Where does Steve Gibson's SQRL fit in here? (If not familiar with it, be sure and read well into the explanation; there's more to it than first impressions convey.)
https://www.grc.com/sqrl/sqrl.htm

Bob
Visitor
Bob
March 16, 2016 1:55 pm

It's still a second step because the authentication could technically be done on another smartphone if the hacker had the cryptographic 'challenge' key.

A smartcard is immutable – once you write data on it you can't transfer the secret data to another smartcard – that's what makes it a second factor.

A smartphone using his SQRL scheme can still have the data copied from it or the data superimposed into another device. That makes it a second step.

There's a good reason that Gibson's scheme isn't used in practice ;-)

Jon
Visitor
Jon
June 14, 2016 6:17 pm

Smartcard's aren't immune to attacks either as data can be copied depending on the implementation; can be easy to hard. For example, Windows Powered Smart Cards render themselves useless if tampered with, it doesn't mean they will always be tamper proof.

This aspect really falls into the strength of the implementation rather than if the solution is actually two factor. Biometric data can also be copied, anything can be broken. What makes it two factor is that two separate containers of information are needed to authenticate (e.g, know, have, are).

Here's some questions:

If I use my cell to store a certificate that I use akin to a smart card (connect to pc), is that a second factor?

What if I send a otp to my cell that is used automatically when connected to my pc, and I don't ever see what it is? Is this still something I know?

Strength of implementation doesn't take away from two factors, sure it can be weak or strong but two factor solutions vary.

John
Visitor
John
March 15, 2016 7:59 pm

Where does Microsoft Identity Manger fit into this, 2ndf factor authentication / verification is achieved by calling the users mobile, the user presses hash and the connection is put through. Is this therefore 2FA?

Bob
Visitor
Bob
March 16, 2016 1:50 pm

Microsoft have a few systems. The one you mention (where you receive a telephone call and press #) is a second step and not a second factor.

Here's a flowchart which describes it nicely:

https://paul.reviews/the-difference-between-two-factor-and-two-step-authentication/

"If it were truly a 2nd factor, it would be impossible to authenticate without the device. If an attacker ports your mobile number to another provider or manages to intercept your SMS by whatever method, they would "know" the OTP and be able to authenticate, despite not "having" the device."

wpDiscuz