Forums » Feature Requests Search

Could there be a way for submitting an obfuscated API key instead of having it lying around in plaintext in the sourcecode of scripting language application that we distribute?

Explain the use case a bit more and also an analog to another webservice that allows this feature so we can check it out? My naive understanding would be that any key you distribute, obfuscated or not, could be "stolen" and used wherever anyone wanted. Why not make a simple EN API proxy and have your distributed app go through that?

You can do this yourself rather easily. For instance, you could keep a base64-encoded version of the api key in your source and then decode it as you are making the API calls. This is akin to basic access authentication. (http://en.wikipedia.org/wiki/Basic_access_authentication ) It is by no means secure, but it does hide keys from the naked eye and avoids having them in plaintext in the source.

Sure, you could use any number of string munging tools -- rot13 would even work. But if you're worried about your key getting used by other people, nothing you can do purely client side will prevent that as the decoding process happens locally; the "attacker" could just print out the URL before it's sent to us. You could however write a few line cgi proxy that took API calls directly to your own server and the proxy merely adds your &api_key=whatever to it and sends it along to us.

Hmm, yeah, Brian's rebuttal is a fair point. And the couple ideas countering that, such as hashing it against a user agent string or, say, a mask of methods this obfuscated key is capable of reaching already get a little ugly in their complexity.

Brian, how do you suggest I stop my proxy from acting as an open proxy to all comers? (and stay on the right side of the ToS) Sounds like I'd quickly get into the over-thinking steps from above, again.

I just saw the google quick search box and thought that a little python plugin might be a fun weekend project. Really easy to hack together, a bit harder to discourage copy-pasta.

Let's put it another way: what do you guys figure are "reasonable measures" to ensure that our API keys go unused by other people, whether by snooping code or by acting as a proxy?

As for other webservices, sadly, I think that's why Twitter and Flickr get into the OAuth weeds.

atl, I had the same problem a while ago working on an app, and I'm in no way a security experts, but here is what I pulled off. This weak solution might no work in your case though.

The app needs to use infos that are in an encrypted XML file. On the client side, I have an auth class that retrieve hardware infos from the client computer (processor ID, ram ID, HDD serial, this kind of thing). All those infos are hashed (I used SHA-1) and gives me the "key". It then tries to decrypt the XML using this key. If the decryption worked fine, I should have a valid XML file and be able to parse it. If not, it asks the user to send a mail with the key.

On my side (authorization side), I have a small tool that takes the unencrypted XML file and sends it back to the user encrypted with it's own key. This allows me to select the computers that can run the software.

This is very very very weak, as various methods can retrieve the key without having to goes through autorization. Plus, authorization means that you have to "manually" allow users and generate a personalized file.

This solution was more of a proof that can be used to justify unauthorized use of the software as I know which hardware it can run on. If it runs on an unauthorized machine, that's against the Final User Licence...

That was a solution I used for a particular software, and unfortunately, the project did not go through for other reasons. Feel free to mail me, I can give you more infos and the source of this hack.

Cheers