Does 2FA solves the problem ?

There are lot of discussion about 2FA and how this will enhance 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 confusion 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 discuss the terminology and explain how any additional security added by 2FA can actually be bypassed by several ways.

Terminology

Lets make it 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 is 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 or swapped without the knowlege. 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 you have it - or that you are  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 all the moment when I try to authenticate"

Your device may be  stolen or 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  2FA 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 CAN WE BYPASS 2SV AND 2FA BY 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 we have discussed 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):

1. The victim receives a phishing email for Service X.
2. Clicks on the link and lands on a login page like the one they expect for Service X, only this time it’s the attacker’s server
3. The victim enters their username and password in the login page
4. The attacker relays (automatically or manually) the username and password to the original service
5. The attacker redirects the victim to a different page where the second factor is required.
6. 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.
7. The attacker uses this second factor to login to the original Service X 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 X, 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. 

 So 2FA/2SV is not 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.

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.

 Things to remember:

• 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.