Twitter’s New Two-Factor Solution Kicks SMS to the Curb
wired.com
wired.com
> 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.
Basically it has a public/private key pair on your phone. Twitter only has the public half of the pair. When a login request comes in it asks you to verify it by confirming it on your phone. Your phone then signs a "Allow" response using your private key that Twitter verifies by checking it against their copy of your public key.
What's cool about this is that it can deal with any login system in existing apps[1], whether written by Twitter or a third party. The two-factor login confirmation is completely out of band from the original login request. If anything the requesting app would just get a login delay.
Would be cool to have a more generalized version of this approach, similar to how TOTP exists. I like the idea of signing login requests using a physical device (eg. your phone) and like how it would be possible to integrate it with existing systems quite easily. What sucks is if each app has to have it's own app installed for something like this. I like how I have a single TOTP app on my phone. If something like this was standardized you could have a single app handling multiple sites.
[1]: If Twitter allows them. It might just reject third party login requests rather then hanging waiting for an "Allow" confirmation from the user. This would actually be an interesting way for them to crack down on third party clients.
We've got RSA 2048 keys on iOS, Android and a separate smartcard USB key, and do 2-factor login and transaction authorization with a simple tap in an app + optional direct login without a password + trusted messaging. Available as an app or an app SDK.
What I'm wondering is whether Twitter is actually protecting the private keys? That's the real tricky part.
What I want is an open standard for this that allows users to change their forwarding service after the fact, preferably without changing anything on the servers they're using it to authenticate with.
And yes, the pals at AuthenTec had some cool biometric and related stuff when I worked with them :), before they were swallowed by Apple. I'm certainly looking forward to what Apple will launch ... but a fingerprint does not magically solve all the issues.
HSMs can do this (no one really does, though); smartcards can too. The problem is no one wants to physically plug a smartcard into a phone, so you're stuck using stuff physically built into the phone. The alternative would be a bt 4.0 le cardholder which talks to the phone, and contains either an internal smartcard or a smartcard slot.
For DOD, there's a badgeholder for the CAC which speaks bluetooth (old, 2.1 I think) to the RIM Blackberry. Updating that to 2013 to work on the iPhone would be pretty awesome, using 4.0le, particularly with a decent smartcard (not sure what the state of the art is; I remember screwing with old javacard stuff with the iButton which sucked.)
SIM cards come to mind.
They could be using whitebox cryptography.
The private key in on your phone. The two factors are: your password, and the private key on your phone. You have to have a phone with the twitter app installed.
And that's a problem if you live in some cities of the so called third world where phones are stolen at the same rate bananas are picked from trees in Congo by monkeys. I don't feel comfortable at all about the "having a phone" part of my authentication process simply because the device can be stolen at any moment. My attorney had 16 phones stolen in the past 5 years. Virtually all the people I know had their phone stolen at least once. And if the idea of regaining access to your account without the phone is "hard" as claimed by Twitter's sec guys... ufff, I won't even bother to install the app thing. I think biometrics is the only security measure that will work in our violent cities here, not only for web services access, but for device usage itself.
Or you know, just don't use a phone... there are plenty of companies offering password management solutions using browser extensions or desktop software.
[1] http://www.cellebrite.com/forensic-solutions/ios-forensics.h... http://www.elcomsoft.com/eift.html
Their 'physical analyzer' doesn't work from the iPhone4S or iPad 2 onwards (under Click here to view all supported iOS devices).
The key is just harder to steal because it is big and is not sent out. But this doesn't seem to have much to do with phones...
The "what you know"-type authentication is literally what you know, not "I don't know it but it's written down on my phone, hang on a sec". You're supposed to be able to provide it without reference to notes (or Post-Its stuck to the bottom of keyboards).
Regarding security, I'd say just the opposite, I'd expect a random PC to be more secure than a random Android phone.
The practicality advantages are that it can sign you in with a single button press, and that it works places that have wifi but not mobile reception (while SMS works places with phone reception but no wifi/data).
That is all good, but one of LaunchKey's biggest features is the Privacy. Each site/app you login to is provided a unique ID that cannot be traced or tracked among sites, ad networks, etc. If twitter opens their 2-factor login up for 3rd Party, it will surely be using this login data in other ways.
Check out LaunchKey (https://launchkey.com) and let me know if you have any questions.
p.s. Our app and system also lets you log out from your device.
If my phone is compromised physically or with malware, this does nothing to protect my twitter account. Both proverbial eggs are in the same phone.
Of course there are still problems with two factor authentication, but it's better than the alternative.
If you lose your phone with two factor auth the provider should give you several temporary keys that you can use, or a way to contact their support line and confirm your identity.
> " or a way to contact their support line and confirm your identity"
That is one of the nice things about SMS 2-factor auth, the backup authentication method (lost phone) is on the wireless company instead of you. I suppose twitter can handle the extra responsibility though. They have ways of verifying accounts, so now it is just a question of scaling that for support.
This is one of the terrible things about SMS 2-factor auth! In exchange for having them be able to replace your phone (so your 2FA works again) you're giving them the ability to spoof you at any given time. From a company's perspective it might be better (don't have to deal with "I lost my ...") but it's a terrible trade off for users.
You should probably take a look at Twitters official blog post which has a bit more explanation[1]. I hear what you're saying about the "Well what if i lose my private keys" because we had the same issue with CACs. Every private key was escrowed somewhere, but you have to remember that this system is optional, not mandatory. This is security measure is designed to help prevent future AP incidents[2].
As far as phone compromise, that's a valid concern. Any large company should policy in place to regulate devices for validating logins (which don't happen that often). As far as individual users, we'll have to see. Since Android is the dominant mobile platform, I'm guessing that malware will be more prevalent on those devices.
[1] - https://blog.twitter.com/2013/improvements-to-login-verifica...
[2] - http://www.huffingtonpost.com/2013/04/23/ap-twitter-hacked_n...
On a serious note, it sounds like they are seriously engineering this so that even someone who has gained access to Twitter's servers cannot access the user secrets:
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.
But if someone has gained access to Twitter's servers, isn't this nuance a bit moot? Presumably if I've gained access to their servers then I can also find a way to tweet as someone else or approve their OAuth requests somehow.
With my 2FA-enabled PayPal account, I can use either my Yubikey USB token or an application on my phone (from Symantec) to authenticate to my PayPal account.
On that site, it "just works" and is painless and doesn't get in the way. I don't want to have to use yet another app or yet another physical device. If you want to "do it right", implement the standards and let the user use whatever they want as long as it conforms to that/those standard(s).
The main advantage I see with TOTP is that it's standardized. I can use any TOTP client with any TOTP server. I can implement TOTP 2FA to my app and it'll work on any compliant TOTP client. A standardized 2FA approach using public/private key pairs would be superior though. You'd get a common approach but with all the advantages I list out in the first paragraph.
Can the average user keep track of just a few different SSL certificates and remember which one to use for which site? No, they can't, and that's why having "multiple IDs" won't work and we'll need some single centralized issuer of certificates in order for it to work "at scale".
With TOTP, 2FA secrets are unique per site, so a rogue agent at company X doesn't gain very much by leaking your, or everyone's, 2FA secrets.
Does TOTP vs public key 2FA have to have a winner? It seems to me like both are fine if properly implemented, and if a public key 2FA system turns into a standard I'm okay with having both. They have trade-offs but for most people and most sites either one is fine. TOTP wins for now because it's a standard and nobody else uses Twitter's system. I don't want an authentication app that only works for one site.
EDIT: Also it's a pain when Twitter's main web site is working but the bit that handles responding to approvals from the mobile client isn't, like, erm, right now.
I can say that every bank and credit card site I've used have vastly, vastly improved their security model in the past 5-7 years or so.
We just submitted a research paper 2 weeks ago to SPSM'13 (http://www.spsm-workshop.org/2013/). We proposed a password-free login system, of which Twitter's new 2-factor auth solution is a special case. We also discussed about the solutions to vender lock-in and 2-factor auth in the paper.
I put the paper in public for interested readers. You can download it from http://about.bozhu.me/paper/loxin.pdf
PS. We did a conceptual Android app about password-free mobile payment, under the same idea, in last year when we participating in the MintChipChallenge by the Royal Canadian Mint. The source code is available at https://github.com/Xecurity/EasyChip
One thing that isn’t clear from the blog post is whether you can have one set of S/KEY backup codes to put in your drawer for when you lose your phone, and another set of backup codes for when the phone is offline (to use just like you use Google Authenticator). Both use cases are important.
Another question is whether Twitter intends to open the protocol and app for third parties to use, as Google did with Google Authenticator[2]. A potential sticking point is that the app probably trusts the Twitter servers to not lie when it tells the app that a particular URL in your browser wants to authenticate, and opening the app probably means depending on X.509 certificate chains in order to trust a server request.
This innovation sounds awesome, but is Twitter exposing their clients to additional risk by returning to a single communication channel? I suppose that Two-Factor isn't designed to withstand a carrier-based MITM attack, and that such an attack would probably apply equally well to data as well as SMS, but I think it's interesting to model the attack surfaces.
All in all I think this is the right direction for Two-Factor, but I wonder if there's a way to use something other than the carrier data channel to deliver the second-factor. There's something to be said for using a diversity of transmission mediums.
Something to think about.
EDIT: For the sake of clarity, I'm referring to a single data channel in that you transmit your password using your cellular data connection and you would also be providing your two-factor challenge over the same data connection, whereas previously the SMS portion represented two discrete networks for authentication.
Where this is somewhat more useful, however, is if you want to provide third party systems with two factor auth and not store a secret per user/service pair. Then twitter's severs being compromised and revealing the shared secret might expose other services. Of course, given how small HTOP/TTOP secrets are, I don't think thats much of a problem.
Note, the usability issue is orthogonal to the protocol. You could easily make an app that does TTOP/HTOP but has the response codes sent by the app with confirmation instead of being entered into login prompt manually, just as you could manually have people enter response for the twitter auth challenge.
thats why twitter HAS to provide robust security for the high credibility accounts or watch those accounts be closed down. anything else is great but thats the REAL driving force is to secure the 140 characters
Read more: http://business.time.com/2013/04/24/how-does-one-fake-tweet-...
* You have to copy the key manually * When a device is compromised, you have to replace the key on all of your other devices
The benefit of sending up the user a code to enter ala Google Authenticator is that we understand secret keys as digitally valuable. The social context of Allow, meanwhile, is that computer users are sometimes trained to click it constantly, e.g. by a desktop app installer or location based app.
If said adversary can steal your password through other means (for example, you use the same password over multiple sites, and the adversary happens to run one of them), they still would have to coerce you into giving the Allow on your phone.
I would understand a bank thinking very hard about this problem, or an email service (most bank account thefts happen not from breaking passwords but resetting them via email, so email inboxes are extremely sensitive).
But a Twitter account? Aren't they over estimating the importance of their data a bit?
I think the real reason is that they are trying to kill whatever third party Twitter clients are left.
Yes. I use it more than email for keeping in touch with people.
You leave your phone sitting around and someone else grabs it? That person can easily authorize a new, permanent login, and you probably won't even realize it.
If you're going to go as far as a second factor like this, why not authenticate the approval?
edit: verbiage and clarity
# Create password
client -> hashit 64-bits-of-random-data 10000 > backup.crypt
hashit 64-bits-of-random-data 9999 > backup.code
tell-user "Write this down!" + backup.code
remote-copy user@server backup.crypt
server -> store backup.crypt
counter = 9999
# Log into the server
client -> request-challenge-from user@server
server -> send-reply "send me hash 9999"
client -> read-value "Tell me the backup code you wrote down" backup.code
try-login user@server backup.code
server -> hashit backup.code 1 > trypw.crypt
if trypw.crypt != backup.crypt
fail "Error! wrong backup code"
else
success "Code good!"
counter = 9998
done
client -> hashit the-same-old-64-bits-of-random-data 9998 > backup.code
tell-user "Write down the new backup code!" + backup.code
If I were them, i'd just do e-mailed password resets and leave it up to the user to secure their e-mail. This complicated scheme is way more likely to be exploited somewhere in implementation, considering how rare and custom it is.
[1] http://www.ece.northwestern.edu/CSEL/skey/skey_eecs.html
Presumably the user must sign not only the nonce, but also the request notification details displayed in the app, so Twitter can verify that the user approved the request it actually sent.
And seems we're not the only ones: https://twitter.com/search?q=No%20new%20login%20requests&src...
Even with another encoding, with 190 bits for 32 characters, that would be 5.9375 bits/character which seems a bit strange to me.
>>> log(62)/log(2) * 32
190.53428193238003
I'm sorry if I'm missing something trivial here.
However, it is not possible to break 192 bits into 58 groups so that each group can be coded in one of those digits. Clearly, some of the bits must end up in more than one of those digits.
base62 is similar to the base10 case, but uses 62 different digits.
If this explanation is insufficient, check http://en.wikipedia.org/wiki/Ascii85. That's for base 85, but the approach is the same.
But I doubt they store the 190 raw bits. Instead, the token is probably generated by appending 32 characters, each sampled randomly from the 62-character alphabet. The result has 190.53 bits of entropy.