Why SMS should never be used as second factor

 June 27, 2018

Lately, all website are urging their users to enable second-factors. The push for multi-factor logins is a good thing from my point of view, since the people are putting more and more details of their life online and is a good thing that companies start to understand the security implication of this and are trying to teach their users good security practices. The real problem is what is defined as second-factor. The possible factors are three:

• the knowledge factor (something you know)
• the possession factor (something you have)
• the inherent factor (something you are)

To have a multi-factor authentication, you need to use at least two of those. The easiest one, and therefore always used, is the knowledge factor in the form of a password. The inherent factor is by far the most complex one, since it requires specialized and expensive hardware. Also due to how those hardware work, is not possible to hash the expected value on the server side, so there is a security risk there as well. For those reasons, the possession factor is the go-to second-factor.

I divide the implementations of the possession factor in multiple categories:

• disconnected hardware tokens
• connected hardware tokens
• software tokens
• fake implementations of possession factor

Disconnected hardware tokens

The most common implementation of this is the keyfob token (with no USB connector), but other form factors are also available. This is by far the more secure class of implementation of possession factor.

Being disconnected means that is pretty much impossible to perform any side attack or infection. Since the key that produces the token is never communicated, this grants very low probability of the attacker knowledge of the key. Also, those devices are usually delivered to the user in a secure way that grants the chain of custody, so that is safer to assume that no one was able to mess with it attempting to extract the key.

The disadvantage is that since the user has to copy the generated code, they often use only digits and contain a low number of them (6 and 8 being the most common). Also, since the whole code changes every time, associating more of those devices on the same account lowers the security, since at every given moment the system will need to accept the displayed code on every single device. If we pick as an example having one or two 6-digits tokens, in the single-token case only 1 combination over 1 million possible combinations is valid, while with two, 2 combinations over 1 million possible combinations are valid, halving the complexity.

Connected hardware tokens

Those devices are very similar to the disconnected hardware tokens but have a significant difference: they get connected (via USB or NFC usually) to the computer so that they don’t require the human to copy a string.

Those devices have the security disadvantage - compared to disconnected hardware tokens - to be (potentially) attackable via the machine they are attached to with the intention of making them leak the private key. Even if this is a risk, those devices are specifically designed to resist to this kind of attacks, so it is a limited risk.

Those devices also have some security advantages. Being directly connected, they can create much bigger strings ensuring less probability of guessing it. Also, many of those have the first few characters that are fixed and identify the physical object, removing the multiple-tokens weaken. Many of those devices support challenge-response authentication which can also be interesting.

One of the problems with this kind of devices is often the implementation which tends to be not so standard. Yubico solved this problem on their Yubikey making the Yubikey act as a USB keyboard. As for the challenge-response authentication, the Universal 2nd Factor has been created with the support of many giant companies to simplify and standardize the process.

Software tokens

Software tokens can be of very different flavor, but usually are very similar to detached hardware tokens, but on a smartphone.

The significant advantage of this solution is the cost. Since the user can use their device, no hardware has to be bought or shipped.

Security wide is less secure than the dedicated hardware alternative since smartphones can be attacked and therefore their content stolen (including the token seed).

Fake implementation of possession factor

Those are methods that can eventually guarantee that the user has the device in their hands. The SMS is probably the best example of those, but not the only one. To make it easier, let’s talk about SMS specifically, but similar problems are affecting the other methods in this category.

The first problem is that all the pieces of information needed to prove the possession are transmitted at the same time of the request prompt of that information. In fact, the SMS containing the exact code that the authentication system is expecting is sent at the same time that the authentication system asks you for it. This is very different from any other way to prove the possession. In fact, the hardware token has to be in the user’s hands before they can attempt to use it, and for software token as well, it has to be configured beforehand. This opens a huge security problem since if someone can interfere with the proper delivery of the SMS, for instance being able to route the SMS differently, the system is easily bypassed. An example of this happened in May 2017 to the O2 Telefónica carrier, where cybercriminals had exploited some SS7 vulnerabilities to route the SMS to phone numbers controlled by the attackers.

The second problem is that the small security SMS provides, is based on the idea that SMS are out-of-band in the authentication (that often happens over the Internet). This assumption is not always valid, and over time this will be less and less true, due to the convergence that is happening between telephone networks and the Internet. The risk is that removing the out-of-band guarantee, it is not much more secure than a saying that CAPTCHAS is a valid second factor.

The third problem is that the phone carrier can read the SMS that is sent or received by its users. This means that the phone carrier and law-enforcement agencies can easily find the digits in the SMS. This can be a problem by itself (i.e., while traveling in some untrusted countries), but can also be a more significant problem, since this is a backdoor on the system, and as all the backdoors, sooner or later, some criminal might be able to exploit it for their agenda.

For those reasons (and others), in August 2016 the NIST has condemned the SMS as a form of authentication. Sadly many companies are still using this insecure authentication method.