NIST declares the age of SMS-based 2-factor authentication over

"NIST declares the age of SMS-based 2-factor authentication over", "End of SMS-based 2-Factor Authentication; Yes, It's Insecure!", "Experts say NIST deprecating SMS 2-FA is long overdue" - these headlines were popular in the last few days after NIST published a draft on digital authentication.

What does NIST suggest?

The most cited fragment of the draft is:"Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. If the out of band verification is to be made using a SMS message on a public mobile telephone network, the verifier SHALL verify that the pre-registered telephone number being used is actually associated with a mobile network and not with a VoIP (or other software-based) service. It then sends the SMS message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change.OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance."

So basically,NIST points that SMS-based 2-FA can be insecure when the telephone number is associated with a VoIP (or other software-based) service.OOB using SMS is deprecated but it is still allowed,however it could be disallowed in future releases of the guidance.

Although the risk of intercepting the GSM traffic exists which makes SMS-based codes insecure, the likelihood of such an attack is very low. What is important, VoIP services can be run on the same machine as the service being authorised with the second factor. As a successful attack requires intercepting both the main machine and the 2-FA device,using a VoIP for 2-FA on a compromised computer significantly increases the risk factor.

Moreover,sometimes the"main machine" is the phone which also acts as a 2-FA device(it is a negation of second factor idea).In this case,a successful attack is much simpler,as it requires to infect only one machine.

Are SMS-based 2-FA really insecure?

First some basics;2-factor authentication (or 2-factor authorisation, I believe both fit into the same category and the first without the second is not complete) methods may rely on one or more of the following:

• What You Have: e.g. time-based physical tokens (usually with a small display), scratch cards with codes, paired mobile app / smartphone
• What You Are: e.g. fingerprint readers, voice biometrics, face recognition
• What You Know: additional password protection for the methods mentioned above

A very important feature of a good 2-FA is to present the action which is being authorised.Assuming the main machine is compromised and the attacker can control its display, a 2-FA device should inform you what action you are "signing". More bluntly: You would like to know if you are sending $5 for a beer to your friend or $5000 to a mule which will be converted to bitcoin or withdrawn at the ATM before you manage to dial your bank. Or: if you are logging in to your mailbox or changing your 2-FA phone number / 2-FA device.

Where is the SMS code here?

It's a combination of What You Have (a SIM card) and What You Know (it may be protected by a SIM PIN and a device lock). It can also present the transaction details or at least its fragment.

What are the alternatives?

NIST suggests a secure application (e.g. on a smartphone),let's talk about pros and cons of the most popular methods:

• Time-based tokens, scratch cards - prove what you have but do not tell which action is being authorised (usability: low, security: low).
• Biometrics (fingerprint, voice, video) - usually prove what you are but ihas been proven many times that they are possible to; in modern phones with a fingerprint reader, the biometric characteristic is verified on the device, not on the server side (which means a vulnerability in iOS Secure Enclave or Android fingerprint API can break your 2-FA) (usability: high, security: medium).
• Password-protected, more sophisticated card readers, physical QR code readers, - prove what you have, prove what you know, informs about the action being authorised (usability: low, security: high).
• Secure mobile applications - they prove what you want but only if they are really secure (usability: usually high, security: depends on the implementation).

As I mentioned, presenting the action being authorised is very important, especially in the case of online banking. This can be done only using some form of transmitting transaction details: by SMS, in network data, in a scanned QR code, by recording a voice on a mobile phone from the computer's speakers, or by any other pair of input on a 2-FA device and the output on a main machine or service provider.

How does the attack on any 2-FA look like?

Apart from external attacks on 2-FA implementation in a specific service - e.g. weak randomness of 2-FA tokens -attacks on 2-FA are targeted. This means in most cases that the main machine is compromised - the other option is that the password is known to the attacker and he needs to compromise only the 2-FA device. Based on my experience, the second situation happens very rarely, and I will continue the analysis with an assumption of a compromised main machine.

Attacks on SMS codes

SMS codes can be intercepted in 3 ways:

• at a telco provider (evil employee, national secret service)
• in an infrastructure attack (registering a duplicate SIM in the network, intercepting GSM traffic)
• on the device (stolen phone, mobile malware).

Attacks on "secure applications"

Interception of "secure (mobile) application"token is more complicated and there are more ways to achieve that. The question is how secure is the "secure mobile application" and what the possible flaws can be:

• token randomness, source of generation, token expiration (external attack, possibly requiring some easily accessible knowledge, e.g. getting Android DeviceID using evil 'Flashlight' application)
• secure storage of the token (weak restrictions of access from other applications, malware)
• improper authentication to the mobile application (device theft, possibly malware)
• who is the token provider (is it the subject of 2-FA, e.g. bank; or external provider, e.g. Authy, Google Authenticator), who has a jurisdiction over the provider
• secure methods of transmitting and displaying transaction details (UI deception)
• SSL channel misconfiguration (weak ciphersuites, lack of certificate verification, no certificate pinning)
• many other

Final threat matrix, SMS vs. secure app

Assuming that:

• Your main device, computer or phone, is compromised (otherwise you wouldn't need 2-FA)
• You use the same phone for secure app 2-FA as you would use for SMS codes (if you are using a separate Nokia 3310 for your 2-FA device, congrats!)
• Your phone is not stolen - because most of the thieves don't know what 2-FA is, and if you lost a phone in a targeted attack, the attackers could use a XKCD-$5-wrench instead.

Then we have one of the following scenarios:

• You are infected with really bad malware which can root your phone and take a full control of it. No matter whether you use SMS-based 2-FA or a secure app, you are owned.Turn off your online banking channel and wait in a queue to the bank teller.If you are using a mobile banking app or mobile banking website on the same phone as for 2-FA (making 1-FA of your 2-FA), you are vulnerable even without hacking your computer.
• Your malware can do only some harmful thing such as getting access to containers of other applications but cannot read SMS messages:SMS codes win.
• Your malware can read SMS but cannot get access to containers of other applications: secure app tokens win.
• Secure app token is compromised by an independent, external attack (e.g. token keys were kept in a cloud which was hacked) - SMS codes win.
• If the SSL connection on your computer is compromised, so can be the mobile phone SSL channel - if the mobile app uses it for exchanging challenge-request tokens and transaction details, there is a possibility for a vulnerability which would allow to change the displayed transaction details on the phone screen, without accessing the token itself - SMS codes win.
• Your GSM traffic is intercepted by a nation-state agency: all your internet activity and bank accounts are already compromised; if your trusted SSL Tier-1 CAs, stop it. Tie.
• Your GSM traffic is intercepted by an individual: this is "APT", targeted attack; as hackers are most likely very lazy, they went out from their cellar and brought a $30,000 device (or $3,000 if they are smarter) near your home to fully compromise your identity just because you use a Nokia 3310 and there is no KingRoot for it. Tie.
• Most possible scenario: you are using 2-FA which makes you far more secure than 99% of other people, attackers will just move to another target. Actually, they now moved to ransomware because it's more effective than hacking bank accounts. Tie.

I leave the likelihood of the above mentioned scenarios to your decision.

To sum up

NIST did not say that SMS-based 2-FA is not allowed. They suggest a "secure app 2-FA", however keep in mind that quickly implemented and not pen tested "secure app 2-FA" may turn into "insecure app 2-FA". There is a need for 2-FA solutions which are secure and have a high usability.There is also a need for testing such solutions.