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.
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.
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 possible for malware to intercept two-step verification tokens as they are 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.
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.
- Two-factor authentication (2FA) versus two-step verification (2SV)
- How to better protect your Facebook account from hackers
- How to better protect your Twitter account from hackers
- How to enable two-step verification (2SV) on your WhatsApp Account
- How to protect your Amazon account with two-step verification (2SV)
- How to better protect your Google account with two-step Verification (2SV)
- How to protect your Dropbox account with two-step verification (2SV)
- How to protect your Office 365 users with multi-factor authentication
- How to protect your Microsoft account with two-step verification (2SV)
- How to better protect your Tumblr account from hackers with 2SV
- How to protect your LinkedIn account from hackers with two-step verification (2SV)
- How to protect your PayPal account with two-step verification (2SV)
- How to protect your Yahoo account with two-step verification (2SV)
- How to protect your Apple ID account against hackers
- How to better protect your Google account with two-step verification and Google Authenticator
- How to protect your Hootsuite account from hackers
- How to better protect your Instagram account with two-step verification (2SV)
- Instagram finally supports third-party 2FA apps for greater account security
- How to protect your Nintendo account from hackers with two-step verification (2SV)
- How to better protect your Roblox account from hackers with two-step verification (2SV)
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
38 comments on “Two-factor authentication (2FA) versus two-step verification (2SV)”
Here's a flow diagram with supporting information.
Extremely helpful and detailed resource. Thanks for sharing, Paul!
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".
Stay tuned, Xand. I'm covering Google Authenticator in an upcoming post. All will be revealed.
Did you complete that article?
Here's the link you're after Susan:
So. it looks like we have an answer to the question:
Q: Would Google Authenticator and similar apps count as 2FA or 2SV?
A: Google Authenticator does not count as 2FA but 2SV
Thanks, David, for the excellent explanation of the difference between 2FA and 2SV authentication. You managed to make it something that even I understand.
My pleasure, Randy! Glad I could help clarify the discussion.
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).
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
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.
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.
Some sites ask for a mobile number for 2FV – which IMHO is not very secure at all since it is easily discovered.
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).
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?
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.
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.
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.
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).
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.
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.
"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
You're confused on the two: I didn't have a smart phone until last year but I don't believe that Apple had 2FA at the time but only 2SA (which had other problems too – Bob actually commented on this in another post on this site); they do have 2FA now but after 30 days (I believe was the number) you can no longer disable it. Maybe I’m wrong on when they first implemented it but I don't believe so (I don't recall seeing it initially until after an update of iOS but maybe that's me remembering wrong … for although I have an amazing memory I have had so much going on since the middle of 2016 that it's entirely possible that I’m mixing it up somehow). Anyway, as for the last part.
'At the top of their game' as you put it: I don't see how a SMS not arriving in time is the fault of the service itself where by 'service' I refer to e.g. Apple or Google or… FWIW I have never had a problem with Apple's 2FA; it's immediately there on the devices. Maybe it wouldn't be if they're not all connected to the same WiFi network (not saying that that's relevant to your case)? And I’m sure you'd have to be logged into the same iCloud account but it's there immediately on all devices in my experience. Personally I would say if they're at the top of their game, anyway, they'd have support for e.g. SecurID cards (for one example method). Of course there is an issue here with security; security has a very particular enemy:
Convenience. People tend to be lazy and having long, complex (the two aren't equivalent) passwords as well as other things people prefer (risking themselves and others in so many ways including identity theft, financial ruin, etc.) not having to go through all the extra steps. Finding the right balance is really difficult, unfortunately, and for many things (and this is one of the reasons password ageing is risky – because it's extremely inconvenient and people will find ways of making it much less burdensome) workarounds will be found in other words ways that make it easier to deal with.
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.
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.
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.
Even so I’m almost certain that it's possible to spoof mobile numbers to receive texts. If memory serves me correctly this is what happened to John McAfee. I’m unfamiliar with technology of the US mobile providers you mention though.
As for SMS being a second factor I believe you're arguing semantics at most. Certainly having a a smart card is better than having to receive a text although admittedly it's been over two decades since I have seen one in use and of course even then there are ways it could be compromised. For that matter you can get small key loggers that you attach to the keyboards and then retrieve it later. People might say that they have no access to it but one common method has to do with many people not making sure that the utility personnel are really supposed to be there etc.
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.)
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 ;-)
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.
I think that SQRL qualifies as a "something you have" factor, because it is the "something you have" (your smartphone) that does the authentication; it's not you entering "something you know from something you have".
However, I have yet to see a viable implementation of this protocol. Both the server- and the client-side proof-of-concepts that I have seen are absolutely impractical shit made by amateurs. We tried to implement it for a login page of ours and had to give up in disgust.
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?
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:
"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."
Someone should explain this to Apple: https://support.apple.com/en-us/HT204915
The three possible factors are:
1) Something you forgot;
2) Something you left in the taxi;
3) Something that can be chopped off.
fantastic article to DEBUNK wildly distributed wrong information !!!
thanks, fresh clean
in response to
Vesselin Bontchev who did say on:
February 27, 2019 at 6:04 pm
very well summarised what authentication factors are in REAL LIVE !!!
thanks, fresh clean