Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.
Not to mention having to store the key / secret in the app (unless you use a proxy).
OAuth fails for mobile.
But what I thought was the case was that the Oauth model was just a cumbersome fig leaf allowing an application to say it never touches the users password. That is a benefit in the sense of protecting an application from itself (a well-intentioned application doesn't have to store its users password).
If Twitter really wanted to separate application authentication from Provider authentication, they could do something like have the app send you a message in twitter from which you could give it permissions OR they could give you a series of "application passwords" which you could then give to the applications (one password per privileged level, each password stays valid till you revoke one application's privilege).
Either of those would be both secure and reasonably simple BUT since it requires the user's mind to think two steps ahead, it would make the apps a harder sell and so you've got the present fake security...
In any situation where the requesting application controls the browser you may as well just hand it your password.
Go to this url to authorize app:
Please input credentials: [__________]
No - I'm not serious. The idea is horrible..
But my point is that Oauth doesn't work for security against malicious apps any--fricken--where. Not on the desktop, not on the web, NOWHERE.
The model of one web page opening another web page "for your convenience" is the model of bank phishing spam attacks. You don't control the browser if another page has opened the browser for you. And unless my research terribly misguided, Oauth absolutely requires the initial app's web page to be the actor which opens the authorization page (Oauth 1.1 requires the whole 'handshake' process to happen fairly quickly for God-knows-what-pseudo-security-reason). What's the user's reaction to entering credentials to twitterauthorizationtimstamp.com? "Sure, that makes sense..."
Oauth is like "electronic checks" signed with Photoshop - its a fig leaf of security. It's not entirely bad but it certainly doesn't deliver what it sort-of seems to be trying to deliver.
Inside a native app, that's all it would be. A feel good, since I could create the browsery chrome to look however I wanted (e.g. a URL bar that shows twitter.com when the page is mycredsharvest.com).
The browser chrome is just a handful of native controls the developer could drop into his own views in less than an hour.
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".
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.
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.
The third party must story my password in plain text (yes. it could store it encrypted, but it must be able to decrypt it, so an attacker could too).
Twitter created xAuth; no one forced it on them. It's odd that they would remove it now when they could have moved everyone to the web workflow when they transitioned away from basic auth.
When one further considers that they're giving developers only 2 weeks to comply, it's hard to escape the feeling that this isn't really about security and is more about tightening the noose on third-party developers.
So if you actually want to protect your users, you can now take yourself out of the loop. If you want to fuck over your users, well, you've always been able to do that and you still can do it.
How does this apply to native clients?
> So if you actually want to protect your users, you can now take yourself out of the loop.
That doesn't even begin to make sense for a native client. Insofar as it comes to security, trust, and data storage, the native client is the user, and they can't be taken out of the loop.
This differs quite a bit from a web service, which is a situation in which OAuth actually makes sense.
Oauth doesn't protect the user from malcious apps but it protects the user from dumb app and it keeps apps from "playing dumb" when they give info to a third party.
On the other hand, I know nothing of Xauth. It too may allow you not to save passwords.
While I understand what he's saying, I don't think the risk assessment makes any sense. When is the last time you heard of a native application leaking passwords in a way that made them accessible to someone who didn't already have access to your desktop or mobile phone?
> On the other hand, I know nothing of Xauth. It too may allow you not to save passwords.
With xAuth, you exchange the user's username and password for a revokable authentication token. The application can then use that token for future requests, discarding the provided username/password.
> it keeps apps from "playing dumb" when they
> give info to a third party.
For tech people it is not seamless,
For non-tech people it is worse than 'not seamless', it is entirely confusing.
His point is that the interface is a usability loss, and a big one.
OAuth makes sense for browser based applications/access from one web application to another. It makes no sense for native apps since those can still grab your credentials in a wild variety of ways.
If you agree with that, then you should see that the change from
"Choose xAuth or OAuth, based on preference and usage"
"Use OAuth unless you are the official Twitter client, if it makes sense or not"
But more likely, someone's written-in-a-weekend throwaway app will simply be insecure and eventually unmaintained, and OAuth protects you from that. That means you can safely use someone's written-in-a-weekend throwaway app without having to change your password when you get bored.
If someone comes to your house with rubber hoses and hits you with them until you start posting "i love being hit with rubber hoses" to twitter, well... that's outside the scope of OAuth. So are malicious web browsers and malicious CAs.
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.
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?
OAuth does also remove the burden of securely storing passwords, but so does xAuth.
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.
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.
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. 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.
"You cannot replicate the core user experience of Instagram.com"
I guess it is a matter of keeping potential future monetization options.
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.)
It's not the technical difficulty of implementing that's a barrier. It's the clear "fuck off" signals Twitter has been sending.
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).
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...
Yes there is. I don't trust the developer enough to give her/him my user ID and password so OAuth works for me.
For example, on iPhone you can invoke an HTTP(s) URL, your app will exit, mobile safari opens, and you can then login and know that what you are typing is as secure as the OS/app sandboxing is....take a look at how the Facebook iPhone SDK flow works, its actually quite nice and very easy for users.
In reality, if you want to know that you aren't giving your username/password to a malicious third party, as an end user, you have to deal with a little inconvenience...being redirected in your browser to an SSL page that you trust, for example.
In this threat model, OAuth is practically a security no-op and a huge usability negative.
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).
Clients using xAuth don't store username/password, anyways. They just use it once to request a token, every future request is just like normal OAuth.
No, its dramatically different. If someone has my password then they have full authority over my account right up to and including changing the password itself. If they have an OAuth token they have whatever limited rights I granted to the token (could be read only, or limited to a subset of data, or automatically expiring after 24 hours).
The analogy that is often used is the special set of valet keys that come with some cars. They allow someone to drive the car - but no faster than 20mph, cannot use stereo, etc. etc.
http://stackoverflow.com/questions/4113934/how-is-oauth-2-di... <- this is a pretty nice summary
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.