This project has moved and is read-only. For the latest updates, please go here.

Advice on Securing Key and Secret

Topics: Developer Forum
Dec 21, 2010 at 10:41 PM


I apologise if this is a bit off topic, since it is perhaps a more generic question than one directly related to FlickrNet, but I'm sure (at least some) users of FlickrNet must either be interested in the answer or have one alerady.

My question is how can/should I secure my Api key and Secret for Flickr if I am publishing a .Net application, and indeed an open source one hosted on codeplex ?

It seems to me the keys aren't useful or dangerous for a user to have, and so we're not trying to secure the keys from end users but rather from developers/hackers who may deliberately or inadvertently perform malicious acts under our applicaitons identity. The biggest concern would be a malicious or poorly written application being given authorisation to access a users account because it identified itself as our app so the user decided to trust it.

The problem is that developers and hackers are arguably the hardest group to hide this kind of info from. If I hard code the key and secret in the source, anyone who obtains the (freely available, open) source can see them. If I somehow avoid putting the key and secret in the source but compile it into the released application then anyone with Reflector can decompile the system and find the values. Even if the values are encrypted, decompiling the source will show you the algorithm used and the where the keys came from/what the keys are/how the keys are generated, so then it's a simple matter for any developer or hacker to decrypt them.

One StackOverflow post I saw on the subject suggested putting the keys behind a web service on a web server, but I don't see how that helps since anyone who can call a web service could retrieve the key unless there's some other kind of authentication to the web service itself and I don't know what that would look like since there could be random clients all over the world who want to access it. I also don't have a web server to put the service on, and it would need to run SSL to truly protect the keys since any decent developer or hacker could just sniff the packages sent to the web service while running the app even if there was some kind of clever authentication to the service itself.

Some suggestions I've seen on the web are not to provide a key and secret myself, but to force each user to get their own. I don't want to do that... too hard/confusing for some users, and breaks all the statistics gathering on Flickr around number of registered users/api calls etc. Another suggestion is to store the values encrypted in a config file, but I don't like that either... it's no more secure (and perhaps less so) than storing the values embedded in the binary in an encrypted form, and since I don't want anyone to be able to change the keys used by my app they really don't deserve to be 'configuration settings' that can be edited.

All I can really think to do is make it as difficult as possible by;

1. Embedding the key and secret in the compiled app somewhere (let out of the published source, but put in the source or a resource file etc. just before the release is built) and,

2. Storing the embedded key in an encrypted form and decrypting it at run time and,

3. Using obfuscation to make determining the descryption algorithm/keys and even the encrypted value itself as hard to find as possible.

Is that as good as it gets, or is there a better plan I haven't thought of ?

Thanks in advance.


Dec 23, 2010 at 4:12 PM

I'm afraid I've never really given it much thought. As you rightly say its not a problem restricted to just .Net users, but anyone who develops open source desktop apps.

Personally I wouldn't include the API key in the source but would enter it during the build process somehow if possible, but other than that I don't have much in the way of advice.


Dec 23, 2010 at 7:37 PM

Thanks Sam,

That was pretty much what I was thinking.

I appreicate your taking the time to reply.

Happy holidays.