Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=240159568
Dubbed "login verification," Twitter's new approach eschews sending one-time codes via SMS to a phone. Instead, the second factor is provided via a unique, private key that resides only on a user's Android or iPhone, and which is generated by the Twitter app.
"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," said Twitter security engineer Alex Smolen in a blog post.
If a user enables the feature, whenever someone attempts to log into his Twitter account -- using a valid username and password -- the site then sends a push notification, requesting verification, to the user's smartphone.
[ Who's worth following? Read 10 IT Leaders To Follow On Twitter. ]
"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 [one-time request ID]," said Smolen. "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."
What happens if the smartphone that's been used to generate the private key for a user's Twitter account goes missing? Helpfully, Twitter now offers a one-time-use backup code. "We encourage you to store it somewhere safe," said Smolen, who noted that this code is randomly generated, using an algorithm inspired by S/KEY. In addition, that code is hashed 10,000 times "to make the backup code work without sharing secrets," he said, meaning an attacker shouldn't be able to reverse-engineer the code and recover a password.
Smolen said the move to an SMS-free system defends against the potential that the server being used to generate one-time codes might be compromised. "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," he said.
The approach also sidesteps the problem of smartphones being infected by malware that could intercept one-time SMS codes. That capability already has been seen with Android malware that's designed to intercept mobile transaction authorization numbers (mTANs) -- one-time codes -- sent by some banks to customers before approving a high-value transaction request.
"No malware that I know of has gone after non-bank SMS codes. But to do so would be extremely trivial for such malware," said Sean Sullivan, security advisor at F-Secure Labs, via email, who called Twitter's SMS-free approach "a useful feature."
Referring to the Syrian Electronic Army (SEA), Sullivan added, "The SEA kind of cooled off, at least on Twitter -- if not Channel 4 -- but there will definitely be attempts on high-profile accounts in the future."
Twitter first began offering two-factor authentication in May, following a number of embarrassing high-profile takeovers of Twitter accounts by the likes of the SEA. Those takeovers included a hoax post via the Associated Press (AP) account about a bomb at the White House that lead to a temporary plunge in the Dow Jones industrial average.
But Twitter's first two-factor authentication system was relatively basic, and many security experts recommended avoiding it. That system involved sending a one-time code to a mobile phone via SMS, which a user then needed to input into the Twitter website. But the system offered no compatibility with authentication software -- such as Google Authenticator -- that might already reside on a user's mobile device. Furthermore, it offered no backup access to accounts if the phone got lost, and was limited to one phone per account, which made it unsuitable for use with group accounts.
Twitter's revamped system seems to have addressed those problems, and perhaps more. "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," Smolen told Wired.
But in the wake of National Security Agency whistleblower Edward Snowden's revelations into the U.S. government's current surveillance programs, there might be more to that statement than first meets the eye, said F-Secure's Sullivan. "The secret is only on the client side," he said. "So I guess the NSA cannot ask Twitter for the secret? That definitely seems to fit Twitter's way of doing things. Maybe the security gag orders have kept Twitter from saying just why they're doing it this way?"