

Twitter’s New Two-Factor Solution Kicks SMS to the Curb - kylerandolph
http://www.wired.com/threatlevel/2013/08/twitter-new-two-facto/?mbid=social10522764

======
sehrope
> 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._

~~~
markkum
The cool generalized version does exist :). Check out
[https://www.mepin.com/](https://www.mepin.com/)

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.

~~~
zymhan
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.

------
aleyan
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.

~~~
echohack
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.

~~~
aleyan
Agree on rule #1.

> " 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.

~~~
sehrope
> 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.

------
brown9-2
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.

~~~
sehrope
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.

------
jlgaddis
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).

~~~
sehrope
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.

~~~
jlgaddis
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.

~~~
hayksaakian
you CAN have multiple IDs, and the ID does not need to be associated with any
personal information.

~~~
jlgaddis
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".

------
BrainInAJar
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

~~~
wmf
Remember that Twitter is a tool for freedom fighters to overthrow governments.

~~~
chrsstrm
As is cash.

------
zhuzhuor
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/](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](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](https://github.com/Xecurity/EasyChip)

------
chrsstrm
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?

~~~
akama
You should check the GeoIP information for your ip addresses. That is most
likely where they are pulling it from.

------
yonran
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.

[1]: [http://msdn.microsoft.com/en-
us/library/ms953432.aspx](http://msdn.microsoft.com/en-
us/library/ms953432.aspx)

[2]: [https://code.google.com/p/google-
authenticator/](https://code.google.com/p/google-authenticator/)

------
josh2600
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.

~~~
sehrope
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.

------
anologwintermut
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.

~~~
rdl
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.

~~~
diminoten
That _has_ to be the next step for this. You don't go through all this work
just for posting 140 characters of text at a time.

~~~
apalmer
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

Read more: [http://business.time.com/2013/04/24/how-does-one-fake-
tweet-...](http://business.time.com/2013/04/24/how-does-one-fake-tweet-cause-
a-stock-market-crash/#ixzz2bE8VZn2J)

~~~
diminoten
That's an excellent point, but they could have implemented something generic
and gotten the same order of magnitude of protection for a _lot_ cheaper.

------
pdenya
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.

~~~
merickson
Isn't this exactly what Duo Security does?

~~~
_jackwink
Very similar, and funny enough: [https://blog.duosecurity.com/2013/02/modern-
two-factor-authe...](https://blog.duosecurity.com/2013/02/modern-two-factor-
authentication-for-twitter/)

~~~
davidandgoliath
I'm glad they patented something that should be used by every service, helping
keep all of us secure :) /s

~~~
_jackwink
Holding a patent doesn't mean you have to enforce it.
[https://blog.duosecurity.com/2013/08/welcome-to-the-push-
clu...](https://blog.duosecurity.com/2013/08/welcome-to-the-push-club-
twitter/)

~~~
woof
Pointing a loaded weapon at you doesn't mean I'll shoot you.

------
angryasian
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 ?

~~~
lamnk
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

~~~
angryasian
I wonder how would twitter implement this safely for the lamen

------
Sargos
Will this work with Google Authenticator or are they making a proprietary app
that you have to use?

~~~
brown9-2
The blog post makes no mention of it. Since it's not HOTP or TOTP, I don't
think it's possible. [https://blog.twitter.com/2013/login-verification-on-
twitter-...](https://blog.twitter.com/2013/login-verification-on-twitter-for-
iphone-and-android)

------
mapgrep
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.

~~~
Mahh
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.

------
laureny
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.

~~~
AJ007
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.

------
bradgessler
When will Github get 2-factor authentication? I emailed them about it a few
months back and they acted surprised.

------
area51org
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?

 _edit: verbiage and clarity_

~~~
InAnEmergency
That person grabbing your phone would also need to know your password, so it's
not any worse than not having two factor authentication.

------
peterwwillis
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.

[1]
[http://www.ece.northwestern.edu/CSEL/skey/skey_eecs.html](http://www.ece.northwestern.edu/CSEL/skey/skey_eecs.html)

------
jemfinch
> 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.

------
LukeHoersten
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.

~~~
pliu
Same for me. Super weird. I can't wait for the blog post that explains what
code blew up for this to happen.

------
rwfilice
I turned it on and it's broken. Nice launch Twitter.

~~~
alternize
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.".

~~~
deanclatworthy
Having problems here. I get a notification on iOS but when I go there it says
"No new login requests"

And seems we're not the only ones:
[https://twitter.com/search?q=No%20new%20login%20requests&src...](https://twitter.com/search?q=No%20new%20login%20requests&src=typd)

------
lukashed
> based on a 190-bit, 32 character random nonce What am I missing? Shouldn't a
> "character" be 1 byte (or more)? -> 32*8=256 != 190

Even with another encoding, with 190 bits for 32 characters, that would be
5.9375 bits/character which seems a bit strange to me.

~~~
tlb
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.

>>> log(62)/log(2) * 32

190.53428193238003

~~~
srathi
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?

I'm sorry if I'm missing something trivial here.

~~~
Someone
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.

If this explanation is insufficient, check
[http://en.wikipedia.org/wiki/Ascii85](http://en.wikipedia.org/wiki/Ascii85).
That's for base 85, but the approach is the same.

~~~
srathi
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.

------
rdl
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.)

------
knodi
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.

------
joeblau
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.

------
mydpy
This is pretty neat. I will definitely share this idea with my company. We
might be able to overcome some of our security issues with this!

------
daemon13
Any idea how this works with managing multiple Twitter accounts?

------
sinzone
Which service/API do they use to send SMS?

~~~
caniszczyk
They have their own via Cloudhopper:
[https://blog.twitter.com/2010/cloudhopping](https://blog.twitter.com/2010/cloudhopping)

------
woobles
[https://www.duosecurity.com/authentication-
methods](https://www.duosecurity.com/authentication-methods) What? This
exists...

------
pertinhower
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?

~~~
wmf
Maybe you didn't see this:
[http://www.forbes.com/sites/andygreenberg/2011/11/28/twitter...](http://www.forbes.com/sites/andygreenberg/2011/11/28/twitter-
acquires-moxie-marlinspikes-encryption-startup-whisper-systems/)

------
segmondy
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.

~~~
peterwwillis
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)

~~~
jlgreco
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.

