
Twitter’s Shit Sandwich - berberich
http://daringfireball.net/2011/05/twitter_shit_sandwich
======
sriramk
The common OAuth flow inside a mobile app is to show a web browser dialog
which loads Webkit/IE/etc and show you the Twitter log-in UI. Frankly, I have
no idea how to verify this page is actually Twitter's UI - there is no browser
chrome, no SSL lock icon or any other trust indicators. It could as easily be
just a random dialog constructed by the app author. I just don't see the
value-add of OAuth in mobile app scenarios. Note that xAuth doesn't mean the
app stores the passwords - you store a token like in OAuth. Of course, whether
the app developer can be trusted to not store the username/password is a
different story.

Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's
login screen is broken on the Windows Phone browser.

~~~
nigelsampson
This approach which is very common completely breaks the security OAuth was
designed for.

If my app hosts the browser control, then there's nothing stopping me
injecting custom javascript into the page to listen for input events.

Not to mention having to store the key / secret in the app (unless you use a
proxy).

OAuth fails for mobile.

~~~
MatthewPhillips
Can you listen to input events on type="password"? If so that's a pretty big
security failure. I'm going to test it.

~~~
adolph
Yep, here is an example:

<http://jsfiddle.net/CYzFH/>

------
jrockway
I'm OK with requiring OAuth. It's hard to trust third parties with data they
collect themselves: see Sony and Gawker. It's even harder to trust them with
data that belongs to someone else: they might one-way-hash their own
passwords, of course, but they can't do that to your Twitter password. It's
probably sitting in a database, cleartext, for every rogue employee or cracker
to see.

Even if you don't care about someone having your credentials, you can't trust
them not to intentionally or accidentally misuse your account. The only way to
trust a third party is to give them an account that can only perform the
actions that you specify, and that's exactly what OAuth does. Of course you
have to use Twitter's site for that: that's where the trust comes from.

Anyway, I've used Android apps that pop open a web browser for the
authentication part and then return you to the native app. It's, by
definition, not seamless... but it's not confusing or slow or difficult or
annoying. I imagine the experience is similar on iOS and Blackberry. So I
don't see a problem here: all I see is the ability for users to have better
protection over their personal information. That means they will be more
willing to try your product, because the damage it can cause is limited. Less
risk, more opportunity for innovation.

Hardly a "shit sandwich".

~~~
zedshaw
> I'm OK with requiring OAuth. It's hard to trust third parties with data they
> collect themselves: see Sony and Gawker. It's even harder to trust them with
> data that belongs to someone else: they might one-way-hash their own
> passwords, of course, but they can't do that to your Twitter password. It's
> probably sitting in a database, cleartext, for every rogue employee or
> cracker to see.

That's a load of FUD crap the OAuth and OpenID projects perpetuate. If you
can't trust the 3rd party then why the hell are you logging in? If it's a
matter of "they might get hacked" then why is Twitter suddenly special and is
somehow magically more safe? Trust me, based on what I hear Twitter is not
more safe than Gawker. How is a _more_ complicated login system safer? More
complicated things like OAuth are not safer, they're just more complicated.

The entire security premise of OAuth is junk. It's only advantage is that
Twitter/Facebook/Google become the owners of your users and can leverage that
against you or the other site. It's just idiotic to say that the only way to
secure your access to SuperHackable.com is to go through Twitter.com as if
that makes SuperHackable.com better or that Twitter.com has some sort of magic
super powers.

~~~
jrockway
_If you can't trust the 3rd party then why the hell are you logging in?_

Well, you can't really trust _any_ third parties. So, to minimize exposure,
you want to trust as few of them as possible. Now, obviously the Sony incident
shows us how trusting big companies is not a good idea, but in general, bigger
companies are going to try harder to protect your data because they have more
to lose. Your weekend project has nothing to lose if it starts spamming my
Twitter followers. But I really didn't mean to bring up this particular topic;
I apologize.

I'm discussing OAuth in the context of allowing applications to do stuff to
your Twitter account, not to authenticate you as you. So Twitter isn't owning
your users, you are merely allowing users to delegate their Twitter
permissions to you on a fine-grained basis. This is nice because it allows,
say, an app to read my public tweets, but not to send them. Giving an app my
password means it can do anything, and all I can do is change my password
(killing all legitimate apps, too) if it does Something Bad. I think we can
agree that that's sub-optimal.

I personally will not use apps that require me to use a third party to create
an account. I don't mind running my own OpenID server, though, or delegating
it if I'm feeling lazy. I do mind being locked into someone else's platform
forever.

------
tolmasky
Not sure if this would break some TOS or something but can't a native app just
continue asking you for your username and password and just do this oath stuff
in an offscreen webview, making it seem just like with xauth? It's almost
disingenuous to show an in app browser with oath and confuse the user into
thinking he has the same sort of "same origin" security as oath in the browser
-- he doesn't, that webview is completely controlled by the app and thus
offers no additional security over xauth whatsoever.

~~~
mattmanser
From a technical perspective, what you're talking about is something that
would be very brittle and liable to break because of changes Twitter make to
their login pages.

It's also relying on functionality that may be treated in the future as an
attack vector and locked down by either Apple or Twitter. e.g. like the
changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-
unders, etc.

~~~
tolmasky
Everything you are describing being "locked down" happened within the context
of the browser world, not to webviews you control. Again, once you are in
control of the webview you can do _anything_. Think of this way: you could
just implement your own HTML renderer, at which point, once again, nothing
anyone builds in will matter. In fact, why bother embedding a webview at all?
Depending on how they implemented the login, simply download the HTML source
code as plaintext, then issue the post of the form yourself -- no browser
required. Each of these is slightly more abstracted, but you get the idea.

I agree with your point that this may be brittle, but that's kind of the point
I'm making -- you're getting zero new security benefits out of it and
introducing the possibility that many apps use a worse technique to get what
they want done. Also, if you are just manually filling out a form I wouldn't
worry about brittleness too much, you're just looking for two text fields and
then submitting whatever form contains them yourself. Unless Twitter actively
starts trying to create fake form elements or something I doubt anything would
break, and even then, is this really what Twitter wants to get in the business
of building, tricky forms to swat third party apps?

------
tlrobinson
As many others have pointed out, OAuth is extremely susceptible to phishing or
snooping of passwords on platforms where the OAuth flow is done in an embedded
web view, which can be considered "untrusted", vs. your browser which could be
considered "trusted" because you know the URL bar is accurate, and there's no
mechanism for 3rd parties to scrape passwords (well, except for user scripts /
extensions)

OAuth does also remove the burden of securely storing passwords, but so does
xAuth.

~~~
boucher
Of course, OAuth is also vulnerable to phishing in a "trusted" browser, when
you're talking about average users who don't really understand how it works.

One interesting way to provide "trust" would be to have a system wide "OAuth"
view (or, "secure browser," or whatever you want to call it). It would have to
contain some piece of user information, like say your user account name and
photo, that the app itself is never granted access to. That way, if you're
actually paying attention you can verify that the system displayed this view.

~~~
ableal
_It would have to contain some piece of user information, like say your user
account name and photo, that the app itself is never granted access to._

A security seal, defined by the user (one time operation). Yahoo used to have
this, and so does my bank in the login page. May be some text, a doodle or
picture.

Curiously, Wikipedia only seems to know about physical seals. Searching for
"security seal login" yields some info.

~~~
tlrobinson
RSA's implementation (used by BofA, among others) is called SiteKey:
<http://en.wikipedia.org/wiki/SiteKey>

These never seemed very secure to me for the reason mentioned in that article:

 _The obvious flaw in the design is that a phishing site can get the correct
SiteKey info from the genuine site, then serve it to the user, "proving" its
legitimacy[1]. SiteKey is thus susceptible to a man-in-the-middle attack._

But at least it requires the attacker to connect to the website, which gives
them opportunity to block hosts that are known or suspected to be phishing
users.

~~~
boucher
And of course that vulnerability would not exist here, in that the information
would not web accessible, but rather only accessible to the local operating
system.

------
ashbrahma
"I can’t think of any reason why Twitter would force native apps through OAuth
other than to create a hurdle that steers users toward Twitter’s own official
native clients" > I think this nails it.

------
evgen
At what point is someone going to just say "fuck Twitter, Inc." and create a
library of simple web-scrapers that emulates most of the API that twitter has
been trying to claw back from the third-party dev community for the past year
via the standard http interface? Such a library may be brittle, but it can't
be much worse than the "yeah, we told you to do this a couple of months ago
but now we changed our minds and you have two weeks to comply with our new
policy" status that exists now?

------
neovive
On a related note. Did anyone else notice today's removal of the "status"
query string variable and the switch solely to "Web Intents"?
<http://dev.twitter.com/pages/intents>. I believe many Twitter sharing buttons
used the simpler query string approach over the full API with OAuth.

~~~
ramen
Not until you mentioned it. Thanks for pointing this out.

------
terhechte
It's clear that Twitter wants to move innovation in their ecosystem away from
native clients that duplicate their exiting functionality. Instead they seem
to be keen to support projects that offer innovative ways of displaying,
sorting, or working with Twitter's firehose.

Instagram does something similar. Their API terms of use read: "You cannot
replicate the core user experience of Instagram.com"
(<http://instagram.com/developer/>)

I guess it is a matter of keeping potential future monetization options.

~~~
LokiSnake
So pretty much a shit sandwich from Twitter. The thing is Twitter probably
would not have been nearly as successful without all the 3rd party mobile
apps, and now Twitter is screwing with the people that contributed to
Twitter's own success.

~~~
ceejayoz
Essentially, Twitter's API is starting to look like it was secretly an on spec
contest to build their official client.

~~~
LokiSnake
I wouldn't even call it that. They bought out Tweetie and made that their
official client, then proceed to make it a pain in the ass for all other
Twitter apps.

------
philfreo
The flow of OAuth on mobile is not nearly as bad when the app opens Safari to
the OAuth screen, and when the user hits accept/reject they get sent to a URI
like myappname://oauth which the iPhone app can register to mean relaunch the
app

~~~
2mur
You can do the same thing in Android too. You have an application specific uri
that you register in your manifest.

------
guan
Twitter has shown quite a lack of taste in recent months (e.g. dickbar). I
wouldn’t be surprised if they simply hadn’t thought about these issues, and
that it’s not a sinister plan to further encourage use of the official Twitter
apps.

~~~
JCB_K
Seriously...they're not stupid.

------
gcampbell
The deadline has been pushed back two weeks to June 14:
[http://groups.google.com/group/twitter-development-
talk/msg/...](http://groups.google.com/group/twitter-development-
talk/msg/dbe591c0088a4b18)

------
buddydvd
Browser-based OAuth flow (like Facebook's new iOS SDK -- the one that avoids
using embedded webview) has two advantages:

1.) Single sign on. If you're already logged in to the site in the browser,
you don't have to enter your user/password again. Also, if you don't trust the
app invoking the web browser, you can always exit the app and pre-login to
site with the web browser before running the app again.

2.) Optional interstitial pages. Sometimes, your account may be accessed from
some questionable location. The OAuth flow enables challenging users with
additional security questions before giving authorization to the app (e.g.
Facebook's identify-your-friends'-faces challenge, enter-your-birthday
challenge, etc.)

------
ak1394
Wow. I guess I'll be shutting down my feature-phone twitter client because of
it. It's been in life-support mode for about a year, but I guess that's the
end of it.

~~~
mtogo
If /this/ ends your app, it was dead a long time ago.

~~~
ceejayoz
Decisions like this are making it clear that Twitter no longer cares about
third-party clients. That they didn't even consider (that, or they just didn't
care) that two weeks notice wouldn't be enough for many devs to make the
change and get it through App Store approval is quite telling.

It's not the technical difficulty of implementing that's a barrier. It's the
clear "fuck off" signals Twitter has been sending.

------
nhangen
Isn't Facebook doing the same thing? In fact, I just got an email from them
today that they're forcing the issue and all devs must adopt oAuth by
September.

------
zyb09
Yes! I'm glad finally someone like Gruber shared his opinion on this.
Integrating Twitter in native apps has been a huge pain for me and trying to
explain clients why they can't have a native branded user/password dialog in
the app (like "all" the other apps) is really tedious. For such a big player
like Twitter they made it really cumbersome for 3rd partys to do simple tasks
like posting a tweet.

------
daveman692
This would become quite a bit simpler if they also moved to OAuth 2.0 (bearer
tokens over SSL) instead of sticking with 1.1 (HMAC signatures).

~~~
gavinballard
The _type_ of token isn't what at's issue here, it's the method of obtaining
one. OAuth 2.0 doesn't make a distinction between bearer and HMAC tokens
during the authori[s]ation phase, which is what this article and discussion is
about.

By the by, bearer tokens over SSL are not a great option given the lax
enforcement of SSL policy by many actors in the domain. HMAC tokens provide a
much higher level of security (and, contrary to your implication, are
specified alongside bearer tokens with the OAuth 2.0 specification).

------
joe_the_user
Hey,

I'm designing a Twitter desktop client from the ground-up with Oauth. It is
annoyingly over-complexified but doable. I suppose I can take a grim pleasure
that others will have to suffer with me...

~~~
chc
Given that it looks like Twitter might not even allow new clients access, I
reckon you're in for a bit more grim pleasure.

------
beerglass
The biggest issue with Twitter oAuth sign-in that we have faced as developers
is that the Twitter sign-in page does not work at all or is not optimized for
feature phones with smaller screens and not running Webkit based browser.
Always wished that Twitter provided a URL - twitter.com/appname that users
could go to and assign all permissions and got a simple key + PIN that they
could enter in our app to access their tweets.

------
ashbrahma
Ryan Sarver (@rsarver) has posted a response with updates based on feedback:

[http://groups.google.com/group/twitter-development-
talk/brow...](http://groups.google.com/group/twitter-development-
talk/browse_thread/thread/e954fc0f8b5aa6ec/dbe591c0088a4b18)

------
tomkarlo
What if Twitter decides to start putting ads for its own native clients on the
OAuth screen? Given recent history, is there any reason this would be a
surprise?

------
BlazingFrog
> "So long as you remain within the app, there’s no security advantage for
> OAuth in an embedded web view over xAuth"

Yes there is. I don't trust the developer enough to give her/him my user ID
and password so OAuth works for me.

~~~
tolmasky
The point is that this is an illusion. If the native app puts up an in app
browser (which is a very common strategy), then they have access to everything
you type. They can query the page for that same username and password, they
can simulate clicks, they can do whatever they want. And additionally, for all
you know, its not even the real page you are seeing. OAuth security only makes
sense on the web.

~~~
zmmmmm
Well, there are different layers of trust.

I trust the intent of many app developers, I just don't trust their competence
to store my credentials securely. So OAuth still requires me to trust their
intent, but does solve the problem of competence (as long as I trust them to
implement OAuth properly which can also be an issue).

~~~
mnutt
And that's exactly what xAuth is. It just drops the pretense that oAuth inside
a developer-controlled webview is trusted, authenticates directly using
email/password, and then stores a token like oAuth.

~~~
zmmmmm
When implemented using a contained web view I agree, it's not terribly useful
and arguably even harmful. However if the user is directed through the real
browser then they can clearly see where they are logging in and doing the
authorisation. This is partly just a problem with iOS and it's limited ability
to flow and pass data between apps than OAuth per se.

------
chopsueyar
Your CSS fonts are tiny.

------
grandalf
If Twitter were simply to implement Oauth2 this would not be an issue.

~~~
DenisM
How so? Oauth2 still requires a web-browser part to it.

~~~
leon_
OAuth 2 is way less cumbersome than OAuth 1.0a. Switching from username/pass
to OAuth 2 would have been far less a PITA than switching to 1.0a where you
have to encrypt/sign the requests by hand.

[http://stackoverflow.com/questions/4113934/how-is-
oauth-2-di...](http://stackoverflow.com/questions/4113934/how-is-
oauth-2-different-from-oauth-1) <\- this is a pretty nice summary

------
kqueue
twitter xAuth is not secure. Why do you want me to hand over my
username/password to a third party service?

------
drivebyacct2
I'm not giving my username and password to my online accounts to random native
or web apps when the service in online account in question provides oAuth.

~~~
bonaldi
and you can verify the embedded-in-a-web-view-with-no-url-bar login page how,
exactly?

~~~
jmillikin
My browser is already signed in to twitter/identica/whatever page is being
requested. If the login page appears at all, it means the app is doing
something shady.

~~~
ceejayoz
Twitter always presents a login page, even if you're already logged in.

------
leon_
The last time I looked xAuth was not available for everyone. You had to
request access to it and they often wouldn't give you the access.

I didn't get xAuth for my apps so I had to go the OAuth way. And I believe
only a few popular apps got xAuth.

------
Rickasaurus
Cry me a river of data mined tears.

