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.
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?