This post gets shared to multiple “social” websites. The original article is, of course, at tvdw.eu
So every developer who develops an application for Twitter gets these secret keys. Yes, that means that they are secret. And it means that they are supposed to stay secret. When you accidentally give away these keys by putting them in your application unprotected, Twitter HQ will revoke these keys and your application will stop working. Which is bad. However, Twitter only seems to be enforcing this policy on the smaller developers, not the big ones. I have keys stored on my hard drive for several applications – including Itsy, Twitter for iPhone, Twitter for iPad and Twitter for Mac. Yes, really, Twitter doesn’t even protect its own keys. In the case of Twitter for Mac, you can simply open your favorite text editor, search for “consumersecret” (or something like that) and you’ll see an Objective-C function that simply sets the secret. You then simply place a breakpoint on that function with your favorite debugger (in my case `gdb`) and you have the key in less than 5 minutes of work. Yes, that does include download time.
For a lot of secret keys that’s no big deal. The only thing they do is confirm that it’s actually your application sending the requests and not some random API client. For bigger websites which store user secrets in a cookie, it means that you could get access to their accounts by stealing the cookies (although if the cookies were that easy to steal it probably wouldn’t have been too hard to login to that website as the specific user, but okay). However, for the bigger desktop clients (including the 4 I named earlier in this post) it’s a problem: xAuth. Basically xAuth is a system that allows an API client to exchange an username and password for a set of tokens, which can then be used to make API calls. You’d think “so?”, but that’s actually a big vulnerability. Not too long ago a large website (I forgot its name) leaked all of its usernames and passwords. With the normal OAuth 1.0 authentication flow it would take the hackers ages to try every single one of those usernames on Twitter, but with xAuth it’s really simple. After all, that’s what xAuth is for.
But there’s still one more issue: xAuth itself. I believe that it’s too easy to actually get xAuth approval from Twitter. Sure, you have to e-mail api@twitter.com and sometimes you even have to include a screenshot of your app, but it’s fairly easy to just open Interface Designer (or the Microsoft equivalent) and design an interface, make a screenshot of it and mail it to Twitter. They’ll give you xAuth approval, and you can convert your username/password database (which you didn’t obtain properly) to tokens. My own application, ΞTweet, also has xAuth approval. It’s an easy way, sure, but I don’t need it. I could implement a custom xitweet:// URL scheme to do the OAuth dance. It surprised me that Twitter HQ actually granted my request, because you’d think they know that a desktop application doesn’t actually need xAuth.
But somehow I don’t think that Twitter HQ will actually listen to this blog post. After all, they’ve also chosen to do things the easy way, instead of doing things the proper way. And if they do it, why shouldn’t the rest?
Tom