Yes, that is a problem with any app that you distribute that has any embedded 
keys. Unfortunately, you ultimately can't really entirely secure anything you 
ship that a user can run on their own machine. You can however take a few steps 
to make that extremely difficult by encrypting and obfuscating your consumer 
keys/secrets in your app package before you distribute. Nothing is impossible 
to reverse engineer if you can get your hands on it (look at iTunes), but you 
can make it take so long and be so hard that it becomes to hard and almost 
everyone gives up (look at iTunes 9). 

One thing I wish was easier though for desktop apps and OAuth is if most API 
providers would make it possible to have multiple consumers and secrets out for 
the same app at the same time. You can then rotate new ones in constantly in 
your builds and if one key is discovered or extracted and abused and revoked, 
all the versions of your app wouldn't be affected. It's something we do with 
SSL client certificates against our API when we ship a new build (even each of 
our nightly builds has its own certificate). If someone extracts it and tries 
to use it, then we can blacklist that one certificate and it doesn't take down 
all the versions of our apps.  

Zac Bowling

On Jun 12, 2010, at 1:59 AM, Jef Poskanzer wrote:

> I don't understand why you are suggesting this only for open source
> programs.  Were you thinking that an attacker would be incapable of
> decompiling an executable and extracting the secret?

Reply via email to