There is a lot of discussion lately about multi-factor authentication and how this will upgrade everyone's security. Indeed, it is an improvement and it was about time we start becoming more conscious about the security issues related to authentication. As usually though, these discussions generated a lot of confusing and "why it didn't work" moments when we see cases such as Reddit's hack in August of 2018.

Since this is becoming more and more confusing to many people - including security professionals, I decided to add my 2 cents in clarifying the terminology and explain how any additional security added by MFA can actually be bypassed by several ways. In order to keep it simple, this post refers to the common and mainstream cases; there are always corner-cases that don't fit this description 100%.

Terminology

I will start with the simple: what is what.

• xFA: x factors authentication, where x is usually 2 or M(ultiple). The usual clarification is that each factor may be one of :
  • something you know: e.g. a password or a pin. That is usually called a "knowledge factor".
  • something you have: e.g. a hardware device such as RSA SecureID. That is usually called a "possession factor".
  • something you are: e.g. biometrics such as fingerprint, iris recognition etc. That is usually called an "inherent factor".
• 2SV: two step verification, which means that there is a verification step after the initial authentication.
• MITM: Man in the middle. You will see why it's important.
• OTP: one time password; typically code generators.

As it should be obvious, these terms have different meaning and they are neither dependent on each other, nor mutually exclusive. One may have two factors and use them in a single step which is 2FA but not 2SV; or use the second factor as a verification method, in which case it is both 2FA and 2SV. Finally one may use 2 passwords, the one after the other, which is a case of 2SV but not 2FA.

If you look at the image on the top which I found in NIST's site you may notice that the depicted use case is that the user provides the username and password (first factor) first; the second factor is provided before the user logs in. That is a typical two step verification, and probably a two-factor authentication scenario too.

And although 2FA should in theory be more secure than 2SV, it is actually implementation specific how secure it can be.

The SMS case

Based on several recent attacks, the use of SMS as an authentication factor is under scrutiny. That is not surprising because most security professionals know that SMS can be intercepted, or a SIM card can be cloned. Whoever is promoting the idea that SMS is something you have (possession factor) is in trouble, because if it can be intercepted or cloned, there is no guarantee that I have it - or that I'm the only one to have it. So SMS is considered an unreliable second factor as it does not establish possession. That does not make it a different factor though. It is still in the general area of a possession factor (it's definitely not knowledge or inherent factor), but a quite unreliable one.

Other possession factors

We usually refer to one-time code generators (such as hardware device, mobile phone application or computer application) as potential possession factors. What is the difference from SMS? While SMS must be triggered, an OTP device always generates a random code based on a "seed"; that code is confirmed by the server because the server knows that my seed that is in my device can only generate that number at that specific time.

And while the 'triggering' factor of the SMS is a problem since it is susceptible to interception, the 'hardcoding' of the seed is a different problem but with a similar vulnerability:

There is no guarantee that I have my hardware device in my hands the moment I try to authenticate

My device may have been stolen or - if it's a computer or phone application - the seed may have been stolen and used in a different computer or phone application. Of course no attacks have succeeded to copy the seed up to now, but that does not mean that it cannot happen. Actually some implementations exist that allow you to store the seed somewhere unprotected; making such an attack quite feasible and easy.

2SV through an app or phone

There exist implementations of MFA that expect you to verify the login transaction answering a phone call or accepting it through a mobile app by clicking a button. Instead of having the seed in your phone / application you pre-register your phone number or device to receive calls and triggers by the server to verify that you authorize the login action.

If the victim's phone is stolen, whether they use these applications phone call verification or OTP generators is irrelevant. But in that case the attacker cannot just copy the seed - there are other verification mechanisms involved making the mobile application a tad more secure.

How to bypass 2SV and 2FA via phishing

If you think that 2SV and 2FA will save you from credential compromise, you need to think again. It may save you in some cases, but credential compromise is usually happening through phishing. It is quite easy to bypass 2SV and 2FA based on the factors that I explained so far over phishing, just transforming it to a typical MITM attack. Here is a typical scenario for 2SV/2FA options (and is quite simpler for 2FA without 2SV):

• The victim receives a phishing email for Service A.
• Clicks on the link and lands on a login page like the one they expect for Service A; only this time it's the attacker's server
• The victim enters their username and password in the login page
• The attacker relays (automatically or manually) the username and password to the original service
• The attacker redirects the victim to a different page where the second factor is required.
• The victim types in the second factor. At this point it doesn't make any difference if it's a hardware device or a SMS message that gives the second factor; it also doesn't make any difference if it's OTP or triggered.
• The attacker uses this second factor to login to the original Service A as the victim

All the OTP-based and SMS-based second factors are equally susceptible to this attack. The attacker does not even need to intercept SMS messages, does not need to steal or clone any devices or seeds. All the attacker needs is to phish the user.

The same goes with challenge - based messages. If the victims think they are logging in to Service A, they will accept the challenge / verify the login in their relevant application.

Unlike typical phishing though, the attacker does not get persistent access to the compromised service. But that's a different thing; the attacker now has an authorized session and we shouldn't be in this situation at all.

How to bypass 2SV exploiting System1 thinking

If you're not familiar with System 1 and System 2 thinking I suggest you have a quick read.

The implementations of MFA that expect you to verify the login transaction can be bypassed. There are cases that people receive a verification message and just accept it because this is what they always do.

The problem is that a system that sends you a verification request every time you login is expected to move the response process in your brain to System 1 thinking. If the attacker chooses wisely the time (e.g. a bit after the user has logged in, but not too much after), then the victim may verify the login even though the victim did not initiate it. This is common in systems that are known to provide random re-authentication requests, or in rollout periods when end - users are not comfortable with the 2SV solution and just accept everything.

So 2FA/2SV is no good?

That would be a very wrong statement. 2FA/2SV is much better than single factor authentication. It definitely has its value, but maybe it needs to get better to provide better value. Solutions exist and they are not even very technically challenging to implement. Although they are not widely implemented due to usability / standardization issues.

Solution to MITM: Authorized device

That is a simple variation of the possession factor idea. The device from which you try to reach the service has to be known and pre-registered. This transforms your device to a possession factor and takes care of MITM attacks, although it still leaves us open to stolen device attack. It is usually based on certificates on the device. Certificates are a well known technique in security that has been proven quite efficient for several use cases. WebAuthn is a great step towards standardization and modernization of this idea extending it somehow to not be limited to the currently used device for usability reasons.

Solution(?) to MITM attack: Specific Challenge - Response

Challenge / Response is a very old idea, used in computers for ages. In this case it means that instead of the device generating OTP codes based on a seed, the codes are generated as a response to a challenge issued by the server. The challenge may be sent before authentication (making it a single step multifactor authentication) or after the first authentication (making it a two-step verification, multifactor authentication). And this is what the verification applications do.

The problem with that is for the challenge/response to make sense, the challenge has to be - as much as possible - linked to something unique. You cannot just issue a challenge for the login process; it's too generic and as explained, unreliable.

You may issue a challenge for a bank transaction though, as many banks do (through SMS). That is a uniquely generated challenge based on the transaction details. The best solution in that case would be to have an application in your end; a dummy device that generates codes based on a seed won't do.

Obviously, this can only be used in critical transactions. We cannot just expect users to re-authenticate every time they wish to send an email. Which brings us back to the authorized device or a combination of the two.

Solution to System1 thinking: Slow down the response

The solution to bypass the System1 thinking "bug" would be to present enough information to the user to understand what the user is validating; but that would beat the usability (plus it's a matter of time until users switch to System1 thinking again).

One could also ask the user to perform an action instead of just clicking the button; something like presenting and asking the user to retype the website they try to login to and the country where they try to login from based on IP geo-location. It will keep the response to be at System2 level always, but that would totally be a disaster for usability and user-friendliness.

No silver bullet

If someone is trying to persuade you that 2FA/2SV is a silver bullet to authentication issues, you know better. A lot of the effectiveness depends on the implementation. If we use biometrics as the second factor we improve the security a lot - but biometrics is a different animal on its own. Windows Hello is promising, as are u2f devices that use fingerprints to unlock. Coupled with WebAuthn we have a very strong solution. That may solve the problem for the next iteration; as usually, when it's mature we have to start thinking again as the attackers are already thinking how to bypass these.

Back to basics

As I explained, bypassing 2FA/2SV through phishing is simple. Which means you need to get back to basics:

• User awareness, always a necessary step.
• Perimeter (WAF) technologies to filter out phishing sites etc should be in everybody's agenda.
• Endpoint (mobile or not) protection; do not leave your phone without a PIN if it has an OTP generator for example
• Physical security; do not leave your hardware devices lying around, and do not keep them in your computer bag

What else?

I have left out of this post several issues. One of these is the persistence of the compromise; how the attacker can switch from a single compromised session to a persistent situation. Another one is the risk-based MFA/2SV. Although they are very interesting issues (and of course I have my opinions on them), they belong to a different post.

I find authentication an interesting subject; if you do too and you have something to say, please do so