Nov 21, 2013
Multi Multi-Factor Authentication
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 what "you have".
Most of us carry a small powerful computer in our pockets (cellphone), another computer in our bag (laptop) and sometimes even another smaller computer (tablet). Soon we'll be carrying even more computers. Today you can buy a computer for your wrist, such as the pebble watch and even for your head with Google glasses.
And because computers and smart devices are cheap enough that we can "own" many of them. That brings us to Multi-Factor Authentication and what this means.
We started Authy with the goal of building a modern Two-Factor Authentication framework that took full advantage of the modern world. Our goal is to build the most powerful and scalable authentication framework. We've now grown to a very significant Two-Factor Platform. Today more than 200,000 people use Authy to protect their accounts. That however has lead to some interesting scaling issues. We want to share with you some of these issues and why we think multiple devices are necessary to solve them.
Extending the attack surface
To our knowledge , all of the Two-Factor Authentication systems today are designed to work with only 1 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).
There is a security reason to only allow 1 device. Having a single device means that the attack surface is smaller. When you have multiple devices if any of them gets compromised, your Two-Factor code is compromised.
It's not possible to add more devices while keeping the same attack surface. To minimize the impact however, one can make this choice "optional" while choosing the most secure alternative as the default.
By default Authy will set multi-device two-factor authentication as disabled. What this means for most users is simply that their attack surface will remain unchanged.
We'll also allow account administrators to control how many devices can their "tokens" be on. That means that they can restrict them to only 1 device if so they wish.
But the question still is: why would you want to have multiple devices if it's less secure?
Doing Multi-Factor Authentication at scale is really hard. One of the biggest challenges is how to deal with "device or cellphone" lost.
There have been several approaches to solve the issue. The simplest one of them is to provide users with a set of "master recovery codes" that never expire. Users can then print them and store them somewhere safe. Thus, if they ever lose their cellphone, they can use one of their recovery codes to successfully authenticate and add their new cellphone.
Although this approach is simple, it requires the 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. Furthermore, most of them stored them in insecure places such as their e-mail inboxes - doing so means anyone who compromises their e-mail can later use this codes to persist access to it.
A second approach is to disable Two-Factor Authentication when the user loses their device. This however is tricky. How do you know it's not a hacker who is impersonating the user in order to disable two-factor authentication? For this reason, we've seen that most service providers choose not to disable two-factor authentication under any circumstance. But this also means that some legitimate users will be blocked out of their accounts.
What has worked best at Authy has been using their e-mail plus cellphone number to verify their identity in case they lose their phone. Once they buy a new phone, we send an e-mail to confirm they own it and also a text-message or a phone call with an authentication code to recover their account. If the user proves he owns both, we re-grant him access to his account.
However we acknowledge there are some edge cases that are still unsolved. What if the user requires two-factor authentication to also logon to his e-mail? Although this is also mitigated by the fact that the e-mail provider can usually text him an authentication code or allow him to have a backup phone, that's not always the case. It's also possible that the user loses his phone and requires a new phone number, in which case he will neither be able to access his e-mail nor receive the authentication code on his new cellphone.
Another important thing to consider is that during this time the user is blocked out of all of his accounts. When this happens we've seen that users tend to disable two-factor authentication entirely after the fact, due to the inconvenience. This means the user now is much less secure and will likely not return to using a strong form of authentication in the future. We think this ultimately hurts adoption and solidifies weaker forms of authentication undeservedly so.
To solve this issue we've created a protocol we called inherited trust. Under this model an already trusted device can extend this trust to another device. This means that you can authorize any other device to access your accounts from an authorized device - the new device can also further extend trust to other devices.
When a device is lost you can simply use another device to access your accounts. Further, when you purchase your new device you can simply use old authorized device to authorize your new device instantly. We believe that in the near future you will have so many devices that you'll always have an old device to authorize a new one.
If you have multiple devices and one is lost it creates a potential for your keys to be stolen. When you add multiple devices using Google Authenticator, all of them will share the same keys. That means you would have to go to each of your service providers, generate new keys and re-add them manually.
In practice users will rarely understand this or more importantly apply it. Ideally you'd want a system that when a device is lost it can quickly be revoked and it's painless to do so.
The way we achieve this is by using an intelligent multi-key system. Every-time you authorize a new device, a new set of keys - specific only to that device - are generated and provisioned. All of this process is completely transparent to the end-user which gets his device provisioned automatically.
Further the login process also stays the same. The user can use any of his devices without being aware of the different keys on each of them and we'll intelligently manage the keys on our backend to provide a seamless authentication experience across his devices.
What this also means is that any device can be taken out of the system without impacting the rest of the devices. At any point, if the user or administrator choses, he can remove a device instantly. Also, because the user can disable the device himself without going through the service provider and do so without having to wait to get new keys, we can significantly reduce the window of time between the point when the device is lost to when it's disabled.
The process to do so is also very simple. On any device you can with just a button click remove any other device.
A good authentication system should protect you from persistence. Persistence means that the attacker can have access to your account without your knowledge for long periods of time.
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 it's being used.
To lessen the chance of this happening, Authy never exposes the private keys to users or administrators. This led some users to believe that Google Authenticator or other QRCode authentication systems where a better as they could just copy their key across different devices. But doing so, they are also exposing the keys to users which regularly don't have experience handling keys securely - thus making it far easier for attackers to steal them.
But preventing the key from easily getting stolen is not enough. What if your device is compromised? We've been doing some advance behavior analysis on our backend to detect when this happen, but we've seen GMail's account activity details an excellent solution to prevent and reduce persistence.
Transparency is obviously key here. So built into the protocol is the fact that no device can hide itself from other devices. At any point in time you can see which devices are authorized, where they have been used and when was the last time they have been used.
We believe this transparency will help users manage and detect unusual behavior on their accounts faster than we can.
We think that a well implemented multiple devices two-factor authentication service provides users with added security and user experience benefits while not significantly reducing the security of the system.
As more and more people start using strong authentication systems it becomes important to handle edge cases better while providing a great user experience to ensure continued service. Incorporating multiple devices solves many of the problems users face and should be part of any modern multi-factor authentication system.