Multi-Factor Authentication, where you present “something you know” paired with “something you have.” has been around for decades. Yes, it hasn’t changed much. What has changed dramatically is the what “you have” part.
Most of us carry a small, powerful computer in our pockets (cell phone), another computer in our bag (laptop) and sometimes even another smaller computer (tablet). And because computers and smart devices are cheap enough that we can “own” many of them, you can even buy a computer for your wrist, such as the Apple Watch, or for your head, Snapchat Spectacles.
And that brings us to Multi-Factor Authentication. We started Authy with the idea of building a modern two-factor authentication (2FA) framework that would take full advantage of new technologies. Our goal was — and still is — to offer the most powerful and scalable authentication framework, which has since grown to become a very significant two-factor platform. Today, millions of people use Authy to protect their accounts. That, however, has led to some interesting scaling issues which we feel can be resolved by allowing multiple devices to access a single 2FA account.
To our knowledge, most 2FA systems today are designed to work with just one device. Although it’s true that Google Authenticator can be added to multiple devices, this is not due to an intended design choice, but rather a poor design choice (we’ll explain this later).
What is the rationale to only allow one device per account? Security. A single device has a smaller attack surface than what is vulnerable when using multiple devices. If you have more than one device accessing a 2FA account and any of them gets compromised, your 2FA is also compromised.
So we challenged ourselves to make it possible for users to add more devices without increasing vulnerability. To minimize impact, we decided to make adding multiple devices an “option” while offering the most secure alternative as a default mode.
By default, Authy sets multi-device 2FA as “disabled.” For most users, this means that their attack surface remains unchanged. We’ll also allow account administrators to control how many devices their 2FA tokens can be on, and restrict them to only one device if desired. But the question remains: why would a user wish to have multiple devices if that makes 2FA less secure?
Truth be told, delivering 2FA at scale is hard. One of the biggest challenges is how to deal with “device or cell phone” loss.
There have been several approaches to solving this issue, the simplest of which is to provide users with a set of “master recovery codes” that never expire. Users can print these master codes and store them somewhere safe. Then, if they ever lose their cell phone, they can use a recovery code to successfully authenticate and add a new cell phone.
Although this approach is simple, it requires users to be proactive and organized about their security. When we implemented this solution, we found that less than 1% of users wrote down and stored their recovery codes. Those who did store their master recovery codes kept them in insecure places like an e-mail inbox, which means that anyone who compromises an e-mail account and finds the master recovery codes could later use these codes to access the victims 2FA.
A second approach is a little trickier: disable 2FA when the user loses a device. But how do you know it’s not a hacker who is impersonating the user and hell bent on disabling their 2FA? For this reason, we’ve seen most service providers choose not to disable 2FA under any circumstance. Unfortunately, this also means that legitimate users can be locked out of their accounts.
What has worked best at Authy has been using a user’s e-mail address — in addition to their cell phone number — to verify an identity in the case of cell phone loss. Once a user notifies us that they have acquired a new phone, we send an email to confirm ownership followed by a text message or a phone call with an authentication code to recover their account. If the user proves ownership, we reinstate access to the account. Learn more about our phone change process here.
It’s true that this leaves some edge cases that remain unsolved. For example, what if the user requires 2FA to also logon to his email? Although this could be mitigated by the fact that the email provider can usually text an authentication code to the user, or that the user might have a backup phone, that’s not always the case. It’s also possible that the user loses his phone and requires a completely new phone number, in which case he will neither be able to access his e-mail nor receive the authentication code on his replacement device.
Let’s also consider is that during this time the user is locked out of all accounts. When this happens, we’ve seen users respond to the inconvenience by disabling 2FA outright, leaving the user much less secure and less likely to return to using a strong form of authentication in the future. This ultimately hurts 2FA adoption and undeservedly solidifies weaker forms of authentication protection.
To solve this issue we’ve created a protocol we call ‘inherited trust.’ Under this model, an already trusted device can extend this trust to another device. This means that a user can use a trusted device to authorize any other device to access his/her accounts – and the new device can also further extend trust to additional devices, and so on.
When a device is lost, the user can simply use another device to access protected accounts. Furthermore, when a new device is purchased, a previously authorized device can be used to instantly authorize the new one. Most people have more than one device, so it’s likely you’ll always have an old device on hand to authorize a new one.
It’s understandably a little confusing: having multiple devices and losing one can create the potential for 2FA tokens theft. And protecting yourself further can be inconvenient. For example, when you add multiple devices using Google Authenticator, all devices share the same keys, requiring a user to have to go to each service provider, have them generate new keys and re-add them manually. In practice, users will rarely understand this process or bother to apply it.
The ideal 2FA service would quickly, and painlessly, revoke a device as soon as it is lost. Authy achieves this is by using an intelligent multi-key system. Whenever a new device is authorized, a new set of keys (specific only to that device) is generated and provisioned. This process is completely transparent to the end-user, who seamlessly gets his new device provisioned automatically.
Furthermore, the login process also stays the same. The user can use any authorized device without being aware of the unique keys on each. Authy intelligently manages the keys on the backend to provide a seamless authentication experience across user devices.
In this way, any device taken out of the system does not impact those remaining. At any point, if the user or administrator chooses, devices can be removed instantly. Also, because the user can disable a device without going through the service provider, and do so without having to wait to get new keys, we can significantly reduce the time between device loss and device disabled.
It sounds complicated, but it’s rather easy: just click a button on any device to remove any other device.
In the security industry, the term ‘persistence’ means that an attacker can have access to an account for extended periods without the account owner’s knowledge. A good authentication system should protect a user from persistence.
One of the biggest failures of passwords is that they allow attackers to persist. Unless the attacker does something out of the ordinary, it’s almost impossible to know if your password has been compromised and is being used — until it’s too late.
To lessen the chance of this happening, Authy never exposes private keys to users or administrators, a fact which has led some users to erroneously believe that Google Authenticator (or other QRCode authentication systems which allow users to copy keys across different devices) is somewhat more secure. The problem with this approach is if a single device is lost, all Google Authenticator keys on all devices are at risk of being compromised.
But protecting your devices (and keys) from theft is not enough. What if your device is compromised via a rootkit or other zero-day vulnerability? We’ve been doing some advanced behavior analysis on our backend to detect when this happens, and have also seen Gmail’s account activity detail an excellent solution to prevent and reduce persistence.
Transparency is obviously critical here, so built into the protocol is the fact that no device can hide from other devices. At any point in time, you can see which devices are authorized, where they’ve been used, and when they were used last.
We believe this transparency will help users manage and detect unusual behavior on their accounts faster than ever.
At Authy, we feel that a well-implemented 2FA service, compatible with multiple devices, will provide users with superior security that’s also easy to use — all without increasing vulnerability.
As more and more people adopt strong authentication systems, incorporating multiple devices solves many of the problems users face and should be part of any modern multi-factor authentication system.