After countless account takeovers that compromised brands, news organizations and individual users, Twitter has revamped its authentication.
At the beginning of August, the social media giant made the changes. And, recently, Twitter forced me to reset my password.
The process was exhaustive.
Going first from the desktop, where I chose a new login; to an SMS message, where I was sent a special code; and then finally back to my iPhone where Twitter’s app chose a random 16-digit back-up code for me to plug into my browser.
In the background, Twitter generated a private key on my smartphone that it then sent back to its servers.
In the future, whenever I (or anyone else who demands multi-factor auth) try to login, the protocol will generate a “challenge and request ID” — pinging my phone to make sure that it’s really me who’s trying to access the account.
The method is more secure than other, more traditional multi-factor structures, Twitter explains, in a blog post.
Traditional two-factor authentication protocols require a shared secret between the user and the service. For instance, OTP protocols use a shared secret modulated by a counter (HOTP) or timer (TOTP). A weakness of these protocols is that the shared secret can be compromised if the server is 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.
Other previous attacks against two-factor authentication have taken advantage of compromised SMS delivery channels. This solution avoids that because the key necessary to approve 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.
Twitter also recently installed a security feature that requires users to confirm app logins from their phones.
These techniques, however, could be confusing, says CA Technologies chief security architect Jim Reno, in a blog post.
While I found the new technique generally easy to use, I think the presence of both cryptographic and SMS-based verification, enabled in two different ways, will cause confusion to some users. In fact I was able to confuse Twitter’s servers: at one point I had the server thinking it was using SMS-based verification while the phone thought it was using cryptography. The result was being blocked at the server until I disabled verification at the phone, as well as getting SMS messages containing long, cryptic strings, obviously intended for the app, not the human.
Can banks learn anything from Twitter’s new security standard? Or is single factor username/password coupled with taking a customer out of band — to a call center — when there is a problem the best way to handle online authentication?