How can I keep the secret in an open source app?

[Roberto]

I am starting a free e-book manager (a bit like Calibre) and I want it to integrate as much as possible with goodreads, letting the user see reviews, post them, rate books, sync the tags in books, etc.

However, there is a big problem:

I can't have a "secret" key. Since it's open source, the secret key has to be somewhere visible. In fact, any python program that uses the goodreads API will have the same problem, since decompiling them and finding the "secret" is trivial.

So, what can I do? Do I make each user get a separate secret key?

[Jonathan]

You can have each user, when they set up your system, get a secret key of their own from goodreads. Or the better thing is to use oauth to authenticate each user with the goodreads system.

It's a normal idea to have the user enter their own keys and passwords when interacting with online services. Do not keep your own keys in the source code distribution, and neither should you encourage people to distribute their keys to other people.

[Roberto]

You mean I have to tell each client to register an app and get a key/secret pair? Isn't that cumbersome?

How would I "authenticate each user with the goodreads system"?

[Roberto]

I forgot, this is a desktop app, not a website.

[Michael]

I think it might be best to distribute it with your "secret" key, but it anyone branches it, they should create their own api key.

This is non-optimal, but the alternative is having every user register as an api developer, which nobody wants.

This shouldn't be a problem that "any" python program has, just any client side open source program.

[Michael]

I guess you could have some sort of protected server that hands out your secret key to validated clients, but that seems like over kill.

[Roberto]

And of course it's just moving the problem around, since how would I validate against my server? ;-)

I think I'll just ship the "secret" key as you said in a semi-hidden spot, hopefully that won't be taken as a violation of API policies?

Pretty much any desktop application can have its "secret" taken even if it's not open source (with a bit more work, of course), surely taking it from any Python or Ruby desktop app would be trivial :-(

[Michael]

We won't ban your app for having its secret key exposed, we'll wait until someone else uses your key to do malicous things. :)

I'd love to heard other sugggestion for how to do this. Our api is modeled after other api's, we didn't get creative. It's designed for the consumers to be server-side apps or closed source.

[Roberto]

MICHAEL wrote: "We won't ban your app for having its secret key exposed, we'll wait until someone else uses your key to do malicous things. :)"

Ouch, that makes it kinda hard for us to work on it, if it can just disappear at any time.

I suppose this is just useless for us then :-(

[Michael]

Roberto wrote: "MICHAEL wrote: "We won't ban your app for having its secret key exposed, we'll wait until someone else uses your key to do malicous things. :)"

Ouch, that makes it kinda hard for us to work on it,..."

Flickr uses this same pattern for their api, and I've never had any issues, but it's certainly a possibility!

[Roberto]

Ok, we'll go ahead with the "publish the secret key" path, and hope we don't run into any problems, then we'll see how we manage if it happens.

[Roberto]

How about implementing something like the "Manual Access Token Provisioning" described here: http://hueniverse.com/2009/02/beyond-...

I think that's what twitter is now doing with the PIN it gives you when you authorize an app via OAuth.

Would that be feasible?

[Michael]

We'll take a look, thanks for the link.

We typically give warning to api users before cutting off access, but only when we can.

[Curtis]

I like the idea of a valet key - I also like the idea of controlling the text that the application displays and giving a link to Goodreads to request the valet key - this way the app can cache a key for each user -I did something like this in the pautg draft - on the command line on first run the user has to fill in there secret and access token - but it makes more sense to require the user to auth and then get a valet key that the 3rd party app can use to open there Goodreads data . Honestly - when I am thinking about this I wonder why the app has to have a secret in the first place / couldn't the app just make a request for the users to create a vallet key for the calling software...

[Roberto]

Another datapoint: analysis of app keys, and why keyinvalidation sucks, etc:

http://arstechnica.com/security/guide...