I’m not dead. No, really. I’m not.
Okay, so here’s the deal.
OAuth sucks. Why does it suck? Because it was not designed for desktop applications. It was definitely not designed for open source desktop applications. What do I mean by that?
Suck.
One of the things that OAuth tries to do is verify that the application requesting access to Twitter really is the application that it says it is. This is a good thing – e.g., if you give Buzzbird permission to access your timeline, then you don’t want some malicious application pretending to be Buzzbird accessing your data in Buzzbird’s name. That would suck. It would suck for you (the user whose trust was betrayed), and it would suck for me, because Twitter could mistakenly think Buzzbird is being malicious.
How does OAuth ensure that an application is really Buzzbird, and not some impostor? Well, the application making the API calls has a “shared secret” that is assigned to it by Twitter. The application stores this secret, and sends it along with every request to Twitter (this isn’t exactly what it does, but you can think of it that way).
That’s the crux of the problem.
The secret is embedded in the application. This works just fine for web-based applications where (hopefully) a copy of the application doesn’t end up in the wild, but when you’ve got an app sitting who-knows-where on who-knows-what machine, it breaks down. For open source apps, it’s obvious – if you grab the source code from github you can see the application key. Okay, so let’s say you don’t put the key in the source repo. Well, in Buzzbird’s case, the application is distributed as a bunch of plaintext javascript files. You can easily read through them and find the key.
This is pretty much the worst place to keep your keys (CC Image Courtesy woodlywonderworks)
Okay, so what about compiled files? Well, any semi-competent hacker wannabe can run the strings command on your binary and probably find your key. If not, if you relish the tedium, you might be able to tease it out by dumping the image in a hex editor.
Even the most astute of developers who try to hide the key in the binary, by whatever clever means they have at their disposal, will still leave behind a trace of their key in the app. It will be on the potential hacker’s computer, and he has plenty of free time to find it. There’s no way around it, OAuth is flawed when it comes to desktop applications.
OAuth isn't clever enough to stop this malicious application.
Buzzbird Status
Regardless, I’ve implemented OAuth in Buzzbird (well, actually I implemented Twitter’s browser-free version of OAuth called xAuth, which is even sillier for its own reasons that I won’t get into here).
As you can imagine, a few programmers are griping on the Twitter developer group about OAuth’s shortcomings. Lo and behold, Twitter has announced that it has a solution to plug this hole, and that they will reveal this solution “soon.”
Twitter has even been kind enough to delay the cutoff time after which OAuth would be the only permitted authentication mechanism.
Meanwhile, I’ve got a new version of Buzzbird kinda-sorta ready, and it has Proxy support and identi.ca support. Unfortunately, I’m sitting on it while I wait for Twitter to share their latest idea on how to fix this. Hopefully whatever they announce won’t take me a few weeks to implement, like OAuth did.
I’ll keep you posted.
This entry was posted on Monday, June 28th, 2010 at 20:50 and is filed under Blog. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
4 Responses to “I’m not dead. No, really. I’m not.”
-
pekarryl Says:
thanks… really I apreciate your work.
-
Matthias Says:
Man… that sucks. I just started to use Buzzbird and I like its straight implementation. I wish you good luck that you can come to a nice solution.
-
elebis Says:
Another way to solve the OAuth shortcoming could be adding a buzzbird’s web layer in the middle of the buzzbird desktop app and twitter and other services, in that way you will abstract twitters, identi.ca and others implementations from the desktop app, most of the improvements and changes will be transparent for buzzbird’s users. Another gain would be the posibility to develop a buzzbird’s web user interface (this is optional of course). Thanks for your work, my best regards.
-
Mike Says:
Yep, I considered a middle web layer, but I didn’t want to be responsible for keeping a web service up and running to ensure that the client stays usable. My web hosting companies seem to have a hard enough time keeping my sites up most of the time, sticking a web service in the middle seemed like a recipe for disaster.
