As some of you might know, I write a µ-blogging tool called elmdentica. It is a client side application developed with Elementary, an EFL library oriented towards small touchscreen interfaces. I only recently learned that Twitter is dropping Basic Authentication support coming next June 30th. They claim it’s insecure because:
- with http credentials go in the clear (no problem here)
- with https, some people may think it’s too expensive (only complete idiots)
- applications have to store user credentials locally
As an alternative, they are making oauth mandatory for APIs that need authentication. While their reasoning may make sense in the context of massively concentrated web applications (think Twitpic and similars) this is absurd for client application like those running in your cell phones or computers.
Let’s take a look at the problem…
oauth gives you a consumer key and a consumer secret that authenticate your application. They don’t authenticate the user, they prove Twitter that you’re a legitimate and registered application.
If both key and secret became public, anyone could make an application pretending to be yours. While someone making a clone of your program isn’t a real problem, if someone writes a trojan horse… then there could be a problem, no?
Well, with oauth, both key and secret need to be known by the application during run time. So at any given moment, the computer running your application will have these two important assets. Either because they are embedded in your code, or because you download them live from a site. The fact remains: they are for all practical effects no longer secrets.
In web applications, no user accesses the only running copy of the software holding both key and secret, so oauth works there.
What about xauth?
I haven’t read much about xauth but after reading this page explaining what xauth is, I’m absolutely convinced the problem remains and wasn’t even tackled. The only issue that was solved, by requesting an user’s login and password only once, without need of local storage or visiting a web page, was an usability issue for client applications.
The real problem is still there, so Twitter is wrong and should not drop Basic Authentication from the https interface.
If they do, elmdentica will very likely not work on Twitter anymore. I don’t care much about that, but the users of elmdentica may care. That pisses me off.
What now?
Fortunately, there is a better alternative to Twitter if you value software freedom called identi.ca. More than just using, you can have your own “Twitter” by installing the Free Software that makes identi.ca, which is StatusNet.
At least they have no plans of dropping Basic Authentication. Hurra!
From the xauth page:
This one method then returns you the authorised access tokens in the same way the same method does for OAuth. You should store the tokens as they do not expire, and reuse the tokens for any subsequent API calls. The password can effectively be forgotten after the authorised access tokens are received (unless you need them for third party sites such as TwitPic etc..).
So it is more secure than plain baisc auth, in that the user credentials aren’t stored by the application, only the negotiated tokens. If they are captured by a third party, that party will be able to impersonate the user as far as posting and reading is concerned. But the fact that only token is stored allows the user to revoke those permissions without worrying about having lost his password.
Regardless, xauth should work also via HTTPS, right?
As far as the user is concerned, a dialog asking for username and password still pops up, but then the negotiation is done without his knowing.
It’s not about user security, it’s about application security. oauth/xauth is bullshit security for client applications.
Ah, I see. You don’t want to have to request a key for your application, and then have that key visible to the world. Well, if you must have an approved app key before doing the auth, then that’s useless for non-web apps.
I have no problem with the need to register, I have a problem with implementing a complex and useless “fake security” method that then others can exploit in my behalf to do harm to others in my name.
I have a problem, also, that Twitter wants to make that mandatory from June 30 onwards.