I'm developing a multi-platform app at present which uses Twitter, including authentication via oAuth.
I've looked at lots of existing apps and most of these seem to embed both the id and the secret key inside the app.
What are the risks of doing this? Is it just that someone can "download and inspect" your app binary in order to extract your key - and can then pretend to be your app (phishing style)? Or are there other risks?
Aside from the risks, are there any workarounds or solutions people know of?
The one solution I've seen already is that some people workaround this by routing all twitter calls via their own website - e.g. OAuth Twitter with only Consumer Key (not use Consumer Secret) on iPhone and android - but this seems quite slow and costly - I'd rather not route all calls via my own web service if I can avoid it (or have I misunderstood the solution - is it just the auth that goes via a website?)
The only real danger seems to be someone can impersonate your App and get it banned by Twitter, then you have to users to a new key.
This Google I/O talk has some pointers on obfuscating the code to make it harder to reverse engineer. http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html
The workaround that I came up with is to fetch the secret key from your webserver (over SSL) using an authenticated web service call. You can cache it in the client app (just in memory). Use it when you need to without connecting to the server again.
The downside I see is that someone could probably still run your app under a debugger and inspect the memory and get the key.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With