> The new two-factor system works like this. A user enrolls using the mobile app, which generates a 2048-bit RSA keypair. The private key lives on the phone itself, and the public key is uploaded to Twitter’s server.
> 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.
Looks cool but I'd like something like TOTP where anyone can implement the client side of it. Since everything is done with public/private key pairs it's possible to have a setup with a central party acting as an opaque forwarding service between the client and the server.
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.
Yeah, if the device is unencrypted, which it likely is, and the key isn't passphrase protected, which also seems unlikely, then it should be trivial to access the private key.
There are simple APIs on iOS (and I believe on Android) which allow you to protect private keys and other data in local storage. Once the iPhone 5S with biometrics comes out (90% likely in September), this will be even more meaningful.
Well, yes and no. On iOS you can somewhat rely on keychain, but when the device is jailbroken all the local "simple API" security is gone. Generic Android doesn't really have anything that I would call secure, so there a serious solution needs some heavy lifting.
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.
The awesome/amazing thing is you can actually do this in properly designed systems -- the key is generated on a separate processor (or, on some ARMs, in a special processor mode), and inaccessible directly to everything else; it can only be used to do operations. If you're superbadass, you can let it put some kinds of access control logic inside the trusted envelope too, so you can rate limit requests, or do additional checks (i.e. "you can't sign a request to pay a bitcoin unless the request signature is valid AND the bitcoin address has >4x that amount, or 2 weeks pass after posting public notice...").
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.)
I'm not sure how this works on a PC with IE/FF/Chrome/Opera used as a desktop browser to access Twitter. Will a private key sit on my PC?
I would assume that more account hacks originate from a desktop pc (using brute force attack methods, etc) rather than from a phone, hence a PC requires further security?
When you are designing a two-factor security system, you have to select two of the following three sources of information to authenticate you: something you know; something you have; something you are. In twitter's case, they've chosen 'know' (password) and 'have' (phone).
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.
Someone compromising my twitter account does not compared to having my phone stolen! If your twitter account is a significant asset, you could keep a cheap smart phone on your desk as a smart card substitute, or practice strict password hygiene & not enable 2-factor authentication?
Biometrics is not fundamentally different from using a password lock, just stronger. It's virtually impossible to break iOS' encryption with today's technology.
Or you know, just don't use a phone... there are plenty of companies offering password management solutions using browser extensions or desktop software.
Do you really need to break iOS encryption? I'm not a big pro in iOS but I heard there are many forensic companies which specialize on extracting data from iOS devices, and from their pages[1] it looks like you can extract quite a lot of stuff from somebody else's phone.
Wait, so there's a backdoor, but police doesn't own it? Then I'm pretty sure NSA either has it or has a way to make Apple tell them how to use it, and it is done is some "security letter" manner that doesn't need a warrant and permissions from any non-kangaroo court. This is how these things are done these days. In any case, this confirms the backdoor exists and Apple has official queue for police to use it. One can only guess who else can access it and with which procedure...
Strictly speaking, Twitter does not check what you "have" - it only checks that you "know" the secret key. If I stole your phone, dumped all info there and then returned the phone to you - I still could use the private key to fool Twitter into thinking I'm you, couldn't I?
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...
You've just described a physical token duplication attack. A consumer phone certainly is easier to attack than a SecurID or smartcard, but it's a far sight from a really really long password. For starters, the challenge response is calculated by the phone's hardware, so that the private key is not exposed.
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).
Thanks for mentioning LaunchKey (https://launchkey.com/). I am a co-founder and can confirm that we are doing something very similar but are only in the Authentication space. LaunchKey supports Private Keys stored on your device among other factors. We have iOS, Android, PHP, Ruby, Python and Javascript SDKs with a WordPress plugin and other integrations coming soon. Our system also allows session based or transactional authentication.
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.
The security advantage of this over SMS would appear to be that SMS could be intercepted. Err... okay...
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).
> 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.