When Twitter rolled out two-factor authentication back in May, it hinted that the SMS authentication would be merely a first step in a more robust security solution. Today, WIRED got a better look at the company's just-announced new system that relies on application based authentication--which means it can provide a complete end to end security without relying on third parties or codes sent via SMS.
"When we decided to implement two-factor, we wanted something that was easy to use and didn't follow the same formula everyone else was using," explains Twitter security engineer Alex Smolen.
The new two-factor system works like this. A user enrolls using the mobile app, which generates a 2048-bit RSA keypair. The private key lives on the phone itself, and the public key is uploaded to Twitter's server.
When Twitter receives a new login request with a username and password, the server sends a challenge based on a 190-bit, 32 character random nonce, to the mobile app -- along with a notification that gives the user the time, location, and browser information associated with the login request. The user can then opt to approve or deny this login request. If approved, the app replies to a challenge with its private key, relays that information back to the server. The server compares that challenge with a request ID, and if it authenticates, the user is automatically logged in.
On the user end, this means there's no string of numbers to enter, nor do you have to swap to a third party authentication app or carrier. You just use the Twitter client itself. It means that the system isn't vulnerable to a compromised SMS delivery channel, and moreover, it's easy.
"Other two-factor systems rely on a shared secret," explains Smolen. "We wanted to come up with a design where it is only stored on the client side; the secret's only stored on the phone."
If you don't have your phone, it has a novel method for that as well. As Twitter explains in a post on its engineering blog:
Effectively, what that means is that it's still keeping the secret stored with the user, and not on a server. Hashed values can be advance, but not rolled back. So the value stored on the server won't reveal the code actually needed for authentication. Even if someone were to break in and get the value on the server, they wouldn't be able to log in--they would need the previously generated value which is only stored locally on the device.
The system has been under active development for about a year. When Twitter rolled out SMS-based two-factor in April, that was more or less intended as a stopgap until it could get this more robust method implemented.
"One of the benefits we got from rolling SMS first is we got something out there that everyone could use first and we got to prove a lot of things on the back end," says Jim O'Leary, an engineering manager on Twitter's product security team. The backup solution was one of the more challenging aspects to nail down.
"We were struggling with it because we were wondering what happens when your phone is not connected to a network," says Smolen. "We said let's have some backup way to do things, but we wanted to maintain this idea that we don't want to store anything on the server that could compromise your account."
They came upon a solution based on an S/KEY system first described in a paper published by Northwestern University in 1996, but that had not been previously commercially implemented.
And if you lose your phone, and your backup code? Well, you can still get back on, it's just a bit harder.
"We involved support very early on in the process, we want to make sure people don't lose access to their Twitter accounts even though the nature of this feature is to deny service," explains Smolen. "We realize social engineering is a real threat."
If a user is totally locked out, there will be an option to roll back to SMS, although not without some difficulty.
"We need to be more strict about our rules there," explains Smolen, "and I'll tell you right now we have a big flowchart."
Although it's debuting today, the system is still in active development and will gain more features in the coming months. The company is working on options for accounts that let multiple people access the same account, for example. It's planning to expose the API for the verification end so that some third party Twitter clients can gain authorization without having to generate a temporary password by letting the official Twitter client approve login requests and pass that authentication along.
