Twitter is rolling out an updated login verification system for iPhone and Android that uses a novel cryptographic scheme that is designed to be resilient against attack and ensures that the private key never leaves the user’s device. The system doesn’t rely on SMS to send codes to users for login verification, but rather on a challenge-response system in the browser.
Earlier this year, Twitter introduced its first login verification system, which was similar to ones operated by Google and other Web services. In that iteration, Twitter users who enable the feature will receive an SMS from Twitter with a one-time code that they must enter, along with their username and password, in order to login to Twitter on the Web or another platform. That system, introduced in May, was a first step toward a stronger authentication mechanism for users and it came in the wake of a number of compromises of high-profile Twitter accounts, including those belonging to the Associated Press and The Onion.
The login verification system, which is designed for the iOS and Android official Twitter apps, now avoids SMS altogether and instead uses an asymmetric cryptographic system that generates a public-private key pair. The public key is stored on Twitter’s server as part of the user’s ID material and the private key is stored on the user’s phone.
“Whenever you initiate a login request by sending your username and password, Twitter will generate a challenge and request ID –– each of which is a 190-bit (32 alphanumerics) random nonce –– and store them in memcached. The request ID nonce is returned to the browser or client attempting to authenticate, and then a push notification is sent to your phone, letting you know you have a login verification request,” Alex Smolen of Twitter said.
“Within your Twitter app, you can then view the outstanding request, which includes several key pieces of information: time, geographical location, browser, and the login request’s challenge nonce. At that point, you can choose to approve or deny the request. If you approve the request, the client will use its private key to respond by signing the challenge. If the signature is correct, the login request will be marked as verified. In the meantime, the original browser will poll the server with the request ID nonce. When the request is verified, the polling will return a session token and the user will be signed in.”
That system works nicely for mobile app users, but there are plenty of people who use Twitter on the Web and may not have their phone handy when they need to log in. To address this, when a user enrolls in the login verification system, she is asked to write down a backup code. To make the use of the backup code work when a user doesn’t have access to her phone, where the private key is stored, Twitter came up with an interesting scheme.
“During enrollment, your phone generates a 64-bit random seed, SHA256 hashes it 10,000 times, and turns it into a 60-bit (12 characters of readable base32) string. It sends this string to our servers. The phone then asks you to write down the next backup code, which is the same seed hashed 9,999 times. Later, when you send us the backup code to sign in, we hash it one time, and then verify that the resulting value matches the value we initially stored. Then, we store the value you sent us, and the next time you generate a backup code it will hash the seed 9,998 times,” Smolen said.
The login verification system already has been included in the official Twitter iPhone and Android apps. One of the key changes in the new system is that when a user receives a login request, it will show the time, location and browser for the request, giving the user more information about whether the request is valid.
Image from Flickr photos of Shawn Campbell.
