Choosing a Two-Factor Authentication System

We've been thinking about how to best implement two-factor authentication to better protect our customers' accounts for quite some time now. When, about 6 months ago, my account was targeted by hackers the importance of a good account security became clear. However, as my hacking case illustrates, two-factor authentication alone is not a complete answer.

At CloudFlare, we considered a number of different ways to implement two-factor authentication. We considered building it ourselves and using Twilio, or another similar service, to send authentication codes via SMS to our customers' mobile phones. The problem with that strategy is that it passes the supposedly secure authentication code through your mobile carrier's less-than-secure network. And, again, if there's a lesson to be learned from my own hacking case it's that mobile providers' security is not always the most robust.

We also considered some sort of fob-based two-factor system. Unfortunately, these are generally very expensive and therefore prohibitive for us to offer all our customers. We also considered solutions like Google's Authenticator. It's a well thought out system, and we have a ton of respect for the Google team, but we were nervous about handing another key to identity over to a company whose primary business is search and advertising. Not to mention a bit of a bad taste after a flaw in Google's own implementation of their two-factor authentication system contributed to my hack.

The underlying algorithm used by several two-factor authentication schemes, including Google's, is open and known as the Time-based One-time Password Algorithm (TOTP). TOTP was specified by the Internet Engineering Task Force (IETF) under RFC 6238.

The mechanics of TOTP are relatively easy to understand. To begin, every TOTP user is issued a random key. Both the server and the client has a copy of this random key. TOTP assumes that both the server and the client can synchronize their clocks. When a user goes to login, the client takes the current timestamp to the previous 30-second interval. The client then combines the key and the timestamp.

This combined key and timestamp value is then run through a SHA hashing algorithm. SHA, like other cryptographic hashes, is a one-way algorithm. That the output cannot be used to derive the input. The SHA algorithm's output becomes the authentication code which the user can post to the server as part of the login process.

Since the server has the same random key for the user, and since the client and server clocks are synchronized, the server can also calculate an authentication code using the SHA algorithm. If the authentication code the server has received from the user matches the one the server derived itself then the user's identity can be confirmed.

What is powerful about this scheme is that if an attacker steals the authorization code then, within 30 seconds, it will be useless. This is typically insufficient time for the attacker to gain access to the account. This is particularly effective against phishing attacks, where an attacker convinces a user to reveal their login credentials on a fake website.

If the core algorithm for two-factor authentication is public, then the question comes down to who has the best implementation. We looked at several implementations and were particularly impressed by a company called Authy. The Authy team created a beautiful, simple, elegant app that implements TOTP. Their vision is not to create yet another app you need to install, but instead to create a single place from which you can manage all your TOTP two-factor authentication tokens.

We've been using the Authy app internally for all of our administrative systems for the last three months. The Authy team has worked with us to refine their app to make it as simple and elegant as possible. After months of our own tests, and spurred on by a phishing attack that targeted CloudFlare accounts, we decided to open up two-factor authentication as a feature for all our customers. If you're interested, you can read about how to implement it on your account with just a few easy steps.

The biggest question we continue to get is why we didn't just use Google Authenticator, since a number of people already have it installed on their phones. Beyond the high-level concerns above, there were a number of technical concerns over security and ease of use that we believe made Authy a better choice.

First, with Google Authenticator if you lose your app there's no way you can revoke the app's tokens. This is probably the biggest security flaw with the Google Authenticator app. While it can be mitigated by password protecting your phone, the better solution is to allow the app to be deauthorized. Authy fixes this problem and allows you to revoke the app's token if you lose your phone. That's a big win for Authy over Google Authenticator.

Second, Google's Authenticator can get out of sync when you don't have network access, leaving you in the frustrating situation of not being able to access your account. Since all TOTP systems rely on the clock on your phone to match the clock on the server, if there's not a fairly precise match then there can be problems. I've experienced this myself when traveling and it can be frustrating. Authy has built a significant amount of logic into their app in order to keep clocks in sync even when you don't have network access.

Third, if you upgrade your phone, with Google's Authenticator you have to reestablish all your two-factor accounts from scratch. With Authy, all your accounts are synced, so when you upgrade and re-install Authy everything will be setup the way you expect it.

And there are a number of other well thought out details. Authy uses SHA-2 and 256-bit keys, where Google's Authenticator uses SHA-1 and 128-bit keys — likely not a huge deal for this application, but generally longer keys and more secure hashing protocols are better. When you wake your phone from sleep, Authy will always start with a code good for the next 30 seconds — it's a nice touch and removes the annoyance with Google's Authenticator of having to wait for the timer to expire if you don't have enough time to enter a code. And the interface is cleaner and just nicer to use than Google's.

But we get it. People don't like to have to install another app on their phones. The good news is the Authy team gets it too. They're adding support in the next few weeks for Google Authenticator tokens to their system as well. That way you can use Authy's great UI to access your Google codes through one app.