Twitter turns to app-based two-factor authentication
When Twitter finally offered 2-factor authentication for its users in May, many were disappointed by the offering as its usefulness hinged on verification codes being delivered via SMS, and the feature didn’t work with many mobile carriers.
But as it turns out, the solution was only temporary, and now a much stronger and easier to use alternative has been added.
“Traditional two-factor authentication protocols require a shared secret between the user and the service. A weakness of these protocols is that the shared secret can be compromised if the server is compromised,” explains Twitter security engineer Alex Smolen. “We chose a design that is resilient to a compromise of the server-side data’s confidentiality: Twitter doesn’t persistently store secrets, and the private key material needed for approving login requests never leaves your phone.”
“Also, our updated login verification feature provides additional information about the request to help you determine if the login request you see is the one you’re making,” he points out.
The only thing you need to use this new solution is the newest version of the Twitter app for iOS (v5.9) or Android (v4.1.4). As with the previous solution, the feature can be turned on in the Settings.
Once you choose to do so, you will be first urged to store a generated backup code in a safe place so that you can access your account even if your phone has been stolen, lost, or is broken.
From that moment on, you will be using the Twitter app to approve requests each time you sign in to twitter.com with your login credentials.
“When you enroll, your phone generates an asymmetric 2048-bit RSA keypair, which stores the private key locally on the device and sends the public key, which Twitter stores as part of your user object in our backend store, to the server,” Smolen describes the login verification process.
“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.”
You can then review the request, which contains details such as the time when the request was made, the geolocation from which it was made, the browser that was used, and the login request’s challenge nonce, you can either approve or deny it.
“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,” Smolen concludes.
Login verification with the previously mentioned backup code is also well thought out, so that potential attackers targeting Twitter servers can’t generate one even if the access the data (more details and a helpful animated GIF that explains this verification process can be found here).
Finally, there will be some Twitter clients that will initially not support the new login verification directly, and for them you can generate temporary passwords via your Password Settings.
This new approach would definitely make breaches such as the one suffered by the company earlier this year less damaging, as decrypting the stored hashes would not get the attackers the login information they need to hijack users’ accounts.
It now remains to see if the system works as it should, secure and glitch-free.