> 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).
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.
> " 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.
> 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.
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.
> “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.
What is the advantage of public key crypto for 2FA, other than that someone who hacks the site's 2FA database can't then impersonate you to that site later, so the site doesn't need to do a 2FA token reset on all accounts if there's a compromise?
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.
The disadvantage of Twitter's approach, though, is that it requires the thing that holds the private key to connect to the internet to verify the request. This increases the attack surface (and is potentially a pain if your phone doesn't have internet access, for example if you have no mobile reception but want to use the Twitter web site on a PC with a wired connection). I've been wondering if it's possible to have an offline system like TOTP that uses a private key rather than a shared secret.
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.
Oh I would love to have a single SSL certificate for the client-side that I could use to authenticate everywhere I want to... but until we move towards some sort of global ID system (which, of course, has its own ramifications) I don't see that happening.
Yes, you're absolutely correct. I'm also capable of managing several different client SSL clients (I do it everyday).
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".
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.
American banks perhaps... in Europe, UK, and in Oceania/Asia they've been using 2 factor auth, one time pads, and such for a while. Even quantum encryption.
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.
do you remember only about 4 months ago a fake tweet on associated press twitter account about the whitehouse being bombed caused a stock market flash crash of nearly 1% which is over 100 billion dollars in the matter of 10 seconds or so???
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
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.
yeah, same here. all i'm getting is a "new login request" notification on the phone when trying to login on the desktop browser. but when opening the notification it says "no new login requests", and the website on the desktop jumps to "We're sorry, there were was an error. Please try logging in again.".
Now when I try and log in, it says it has sent a login request to my phone, my phone registers that as a notification, but when the Twitter app opens it says I have no login requests - so still not working.
Finally. I still don't understand why 1) they took so long to do anything and 2) they did the crappy SMS-only form earlier, but this actually looks like what a reasonable person would implement, given the Twitter user model (mostly moving to mobile clients, crossplatform, etc.)
It's base-62, just using the 52 alphabetics and 10 digits. Using just those characters ensures it can be typed and won't be mangled by international, HTML, or URL encodings.
Please provide an example of base62 encoding. With base64, it is trivial to break 192 bits in a group of 6 bits each and assign one of the 64 characters to each (A-Z, a-z, 0-9, /, +). With 190 bits, how is the encoding done?
Here's a hint: base10 encoding those 192 bits just means "write the number in decimal". Since 2^192 is about 6E57, that can be done in at most 58 digits.
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.
Thanks very much.
I understand the generic method now. Base64 with 192 bits is just a special case where both 192 and 64 are powers of 2, which allows simple encoding by grouping the bits.
It's no harder than converting a binary number to decimal.
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.
Biggest problem with SMS is that it cost and its not cheap at high volumes. Twitter pays a lot money to secure short-codes and delivery of SMS into countries around the world. Slowly they'll phase out the SMS auth and save money.
Is there an open-source version of this or does anyone want to create one? I need something like this for my next project, but this doesn't add any value to my product.
What I read: "Blah blah blah...Twitter developed a novel authentication system...blah blah blah." Anyone else think that trusting Twitter (or any other company without vast mathematical and security chops) to securely deploy an existing authentication system, much less develop a new one, is likely to end in tears?
No major advantage over SMS. It just sounds great, but that's about it. If someone has your phone you are compromised be it via SMS or their app. Disadvantage is numerous, (1) if you lose your phone, you are in for a world of hurt trying to reauthenticate, (2) all users without smart phone are out i.e, users in 3rd world countries where data is readily not available but SMS is. I personally think they should have done both.
SMS is a huge security hole; it's not secure at all. Literally child's play to circumvent, intercept and spoof. (Also, unfortunately, they still have an SMS option for when you lose your device, which doesn't make much sense, but whatever)
To add to this, SMS may seem like an unrealistic security hole but you have to consider that there are some very high profile twitter accounts. Intercepting SMS messages may not seem like something your pain in the ass neighbor is likely to do to you, but there are far more interesting targets with twitter accounts than you.
> 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.