> 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.
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?
What happens if I lose my phone? I have human ways of authenticating myself to my wireless provider and getting a new phone with same phone number back. Do I need to backup the RSA private key?
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.
Rule #1 of security: There is no such thing as perfect security.
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.
> “My phone fell in the ocean!”: Backup codes generated in the application can be written down, stored in a safe place, and used to access your account on twitter.com even if you lose your phone.
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.
This is an interesting way to get people who use non-official Twitter mobile clients to install the official client again.
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.
If you have live server access yes (you can do whatever you want at that point). But if you just have a data breach then no. A data breach of the public keys wouldn't require them to reset two-factor auth for the impacted users. An attacker would need each user's private keys to authorize login attempts and Twitter doesn't store that anywhere so it can't be breached en masse from them.
I wish everyone would just use HOTP or TOTP, similar to how PayPal does it.
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).
I used to think that TOTP was the way to go too but it can be improved. I really like having a public/private key pair vs a static shared secret. It's just objectively better. With this setup a rogue agent working at company X can't leak your 2FA secret. Data breaches don't compromise 2FA (this is really important).
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.
Why the hell is Twitter more secure than my bank? I don't actually give a crap if someone steals my twitter account, and I can't imagine why anyone would
It's probably cheaper for them to roll back relatively scarce fraudulent transactions than deal with illiterate users who clog their support with requests about password not working. There are not that many fraudsters out there but a real lot of dull people.
Disturbingly some of my most frustratingly, restrictively simple password requirements for account registration have been banks and credit cards. If I recall, at one point American Express required I choose a password 4-6 alphanumerics.
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.
It is very interesting to see Twitter has the similar idea with ours.
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.
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
So I tried it and my first login request was flagged as coming from N. VA (I'm in CA) which really made me nervous for a good 5 minutes. Next I turned on my private proxy which is also located in CA and the login request was then marked as coming from Amsterdam. Is their location info intended to be accurate?
Sounds like a clean solution, and very similar to smartcard authentication[1]. It improves on smartcards by showing which application is attempting to authenticate. It improves on Google Authenticator by allowing faster authentication in the common case that you have Internet access, and removing the shared secret so they can safely deploy the verification to commodity servers.
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.
Forgive my ignorance, but I always thought the point of using SMS was to avoid using the same data channel for transmission, kind of like having Fiber with a backup DSL/Cable line for a small business.
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.
With this new setup the carrier channel is irrelevant. It could even be done in plain text (eg. no SSL). Since the request is being signed using a pre shared public/private key pair it can't be man in the middled or spoofed. At best someone interfering with your network connection (between you and Twitter) could prevent you from logging in if they mess with your network packets. They wouldn't be able to fake the authorization of a login attempt though.
If only used at twitter, this is useless. They went through the effort and security risk to develop a custom protocol that doesn't involve shared secrets. Good for them. But if your shared secret only allows access to Twitter and is only stored on Twitters servers, its compromise probably entails their severs getting owned. In which case, the authentication schemes don't matter.
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.
The next step, IMO, should be for Twitter to extend this to let third party websites and apps authenticate using Twitter's new protocol. Ultimately could be worth more than Twitter's core business. Essentially Facebook Connect done right, in a privacy-protecting way, with higher security.
Sounds like there might still be some process stuff to figure out but overall this is the least annoying version of two factor auth i've ever heard of. Unfortunately all it can protect is my twitter account.
I'm curious as to how this will handle multiple devices with the a single twitter login ? I have a phone , a tablet and I'm rom a lot so I may have to install the app several times in a say a month. For each device and install wouldn't that generate a new public key ? How would they re verify that ?
It's the same as using your private SSH key to sign in to your servers from different devices, you can choose to generate a new pair of private/public key or just copy your private key from old device to new ones. But reuse private keys have it disadvantages:
* You have to copy the key manually
* When a device is compromised, you have to replace the key on all of your other devices
It won't as it's using a public/private key not the time based auth that Google Authenticator uses. If you don't want to use the Twitter app you can use SMS.
Not a crypto expert so tell me if I'm wrong but isn't the one downside of this the risk that a user will click "Allow" when he should not? I.e. a phishing site stating "if your Twitter mobile app prompts you to Allow, click Yes to receive your free pr0ng/game/claim your inheritance?"
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.
That's only in regard to a phishing attack, but two factor authentication protects you in the case that you lose your password to an adversary who tries to log in themselves.
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.
Regardless of the technical merits of the approach, are there that many people who care about protecting their Twitter account that badly?
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.
Given that companies, individuals, dissidents, and sitting government officials use Twitter as both public & private communication streams in many cases the security of the account is more valuable than a checking account with a couple of thousand dollars in it.
I'm not sure I'm a fan of this scheme. While it seems to solve Twitter's problems for the time being, it gives an incredible amount of power to the person who has your phone — which may not be you. Being able to authorize a new login without any kind of authentication on the administrative side (as managed by the Twitter client on your phone) means that anyone in possession of your phone is in charge of your account.
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?
It does sound like the public-key crypto is one of the best ideas for internet-enabled 2-factor so far, though I haven't quite wrapped my head around the implications of the weird "hash it one less time" backup code method. Based on the description on the skey page here[1], here's some pseudocode of how the challenge works without your phone:
# 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
Edit: so every time you attempt to use a backup code, if it works, you write down a new backup code. Depending on how they implement this, there's a couple fun attacks based on things like the randomness of the pad, if we can force it to reduce the rounds used over a pad (which might not even matter if it's something fast like SHA1), etc. The [remote] security of the second factor now depends on whether or not you can guess a 60-bit "random" hash. Fun stuff.
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.
> 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.
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.
It's broken. Instead of sending web login requests to the app "login requests" area, they're still sending SMS messages. The SMS messages used to include a 6-character token to login but it's been replaced by the 256-character signature. This can't be used to login with and nothing shows up in the app "login request" area. It looks like the old SMS system and the new 2-factor auth system are conflicting with each other.
[+] [-] sehrope|12 years ago|reply
> 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.
[+] [-] markkum|12 years ago|reply
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.
[+] [-] gcr|12 years ago|reply
[+] [-] zaidmo|12 years ago|reply
[+] [-] thomc|12 years ago|reply
[+] [-] rhizome|12 years ago|reply
[+] [-] aleyan|12 years ago|reply
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.
[+] [-] echohack|12 years ago|reply
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.
[+] [-] joeblau|12 years ago|reply
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...
[+] [-] brown9-2|12 years ago|reply
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.
[+] [-] sehrope|12 years ago|reply
[+] [-] jlgaddis|12 years ago|reply
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).
[+] [-] sehrope|12 years ago|reply
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.
[+] [-] BrainInAJar|12 years ago|reply
[+] [-] wmf|12 years ago|reply
[+] [-] smsm42|12 years ago|reply
[+] [-] stinky613|12 years ago|reply
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.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] zhuzhuor|12 years ago|reply
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
[+] [-] chrsstrm|12 years ago|reply
[+] [-] akama|12 years ago|reply
[+] [-] akama|12 years ago|reply
[deleted]
[+] [-] akama|12 years ago|reply
[deleted]
[+] [-] yonran|12 years ago|reply
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.
[1]: http://msdn.microsoft.com/en-us/library/ms953432.aspx
[2]: https://code.google.com/p/google-authenticator/
[+] [-] josh2600|12 years ago|reply
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.
[+] [-] sehrope|12 years ago|reply
[+] [-] anologwintermut|12 years ago|reply
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.
[+] [-] rdl|12 years ago|reply
[+] [-] pdenya|12 years ago|reply
[+] [-] merickson|12 years ago|reply
[+] [-] angryasian|12 years ago|reply
[+] [-] lamnk|12 years ago|reply
* You have to copy the key manually * When a device is compromised, you have to replace the key on all of your other devices
[+] [-] Sargos|12 years ago|reply
[+] [-] brown9-2|12 years ago|reply
[+] [-] ropiku|12 years ago|reply
[+] [-] mapgrep|12 years ago|reply
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.
[+] [-] Mahh|12 years ago|reply
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.
[+] [-] laureny|12 years ago|reply
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.
[+] [-] AJ007|12 years ago|reply
[+] [-] mkr-hn|12 years ago|reply
Yes. I use it more than email for keeping in touch with people.
[+] [-] bradgessler|12 years ago|reply
[+] [-] area51org|12 years ago|reply
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
[+] [-] InAnEmergency|12 years ago|reply
[+] [-] peterwwillis|12 years ago|reply
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
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jemfinch|12 years ago|reply
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.
[+] [-] LukeHoersten|12 years ago|reply
[+] [-] pliu|12 years ago|reply