views:

140

answers:

3

If I have an app that connects to Amazon's S3 service, is it worth my time to hide/obfuscate the connection strings and API keys? I'm guessing that most hackers won't care all that much, but it would be financially painful if someone found this information and was able to upload data to my account!

For instance, if I store a username/password (or Twitter/Facebook API key and secret), these may be easily found using "strings". A hacker could see the functionality, grab the secrets and use them for nefarious purposes. I've seen people suggest using a simple Rot13, or storing the strings backwards or something like that in the app binary. Are these useful?

Has anyone done this or have any ideas/patterns/code to share?

-dan

+1  A: 

You dont really need to hide them...what you should do is have an extra key such as a secret, that one IS hidden and is only present in the signature of the call (which can be an MD5 hash or sha (or whatever)) without that secret key people wont be able to just make calls since the signatures created by the server and the offender wont match since they dont know the secret key used...

Daniel
How do you hide the secret key?
Phillip Jacobs
It's included in the signature , u can make a signature say by having parameters followed by an equal sign and it's values in abc order on a string the append the secret key to the end, take the sha hash or md5 hash of that and send it as the signature to the Service call, on the server side the same steps take place , only if the signatures match do you allow for the call to proceed
Daniel
If the attacker can read the secret key by running your binary through strings. Reverse engineering the generation of your signature is trivial.The trick is keeping the secret, secret.
Phillip Jacobs
well its supose to be hard to reverse engineer hashes...this is what apis like facebook do...if it wasnt so safe they prolly wouldnt be doing it
Daniel
also u can use ssl as an added layer of security
Daniel
A: 

I'm guessing that most hackers won't care all that much

It just takes one who's bored enough.

Has anyone done this or have any ideas/patterns/code to share?

This is what SSL is for. You can encrypt all your transmissions or just the login process (which would return a session id that can be used for subsequent requests during the session).

webbiedave
SSL would help, but if the service credentials were stored in the app binary, running "strings" will spill all the secrets, then the hacker can just login to S3 as me and do what he likes.
Daniel Blezek
+1  A: 

You can hide your secrets in a webserver you have full control over, and then having this server relay the query to Amazon. You can then use whatever encryption/validation method you like, since you are not relying on what is supported by Amazon.

Once you have validated that the request is from your own application, you then rewrite the query including your secrets and then forward this to Amazon. The result from Amazon could then be relayed directly back to the application.

In php this could for instance be done using something similar to this snippet (not showing your url rewrite):

$fp = fopen($amazon_url,'r',false);
fpassthru($fp);
fclose($fp);
Claus Broch
This is helpful, but I didn't want the overhead of running my own server (I'd rather let Amazon do this). But it's a good suggestion.
Daniel Blezek
So run your server on EC2 then...
caf