Where to store hashes, salts, keys in Desktop Applications

Question

I am trying to figure out where or how i should store application secrets and keys inside a desktop application. For example a facebook app key or dropbox key and secret.

So I've read that i should hash, salt, encrypt etc etc these values. This is to prevent someone from reverse engineering my code and seeing the keys.

The is all good and well, but with all these methods, i'm just storing a salt or hash value somewhere instead of the key itself, in the end. Surely if a hacker can get to the salt/hash and possibly the source code, they will be able to decrypt the encrypted key and get my password/key/secret anyway?

One option I've read about that seems the most secure is to not store this value in the desktop app at all, but to call a web service to obtain the key (probably encrypted). But my question is, even in this case, a decent hacker will surely just do a memory dump or something to see what the value returned from the web service is, and then we're back at square 1.

The next best alternative seems to be obscurity.

Am I missing something completely?

On a side note, what use will a facebook/twitter/dropbox/etc key/secret be to a hacker anyway? Surely they would still need a user's credentials or access token to be able to use it anyway?

Any advice or suggestions will be appreciated.

Answer 1

TLDR: you cannot keep anything secret in a client application, you can only make it harder to find. You need to obfuscate the secret key to make it hard enough for an attacker to want to reverse engineer it.

client applications, which have to be deployed to the end user device are subject to reverse engineering and hence NOTHING can be kept secret. But it is true that you can make the process of reverse engineering certain parts of your application hard, sometimes hard enough to make it not worth the effort, by using obfuscation.

using a hash and a salt will not help you since a hash function is a one way function - it can be used to validate a given input's hash is identical to what is expected. It cannot be used to encrypt data, since there is no method to decrypt.

You can use symmetric encryption such as AES, but still the encryption key will be needed to decrypt the data and hence will be also available to the attacker.

Keeping the secret on a server and calling a web service, as you noted, is useless since the attacker can call the web service just like your client application can.

So the real only means of protecting your secret is using obfuscation which will make it not worthwhile to an attacker to do the effort of reverse engineering it.

IMHO in your case, a secret key for an API is sensitive data, but not critically sensitive. Anyone can obtain an API key of his own, and as you noted on itself does not grant you permissions to any users data. It is just for the service provider to track who is doing the API calls, and sometimes in certain API's to monitor usage, limits and even fee's. So you risk is someone stealing your API bandwidth of calls and maybe even causing you to pay for their usage of the API. On the bright side - such keys (facebook, twitter...) are very common, today almost in every application, and hence its enough for your to make it just a bit harder than usual in order for the attacker to just leave your application alone and go grab a sercret API key from another application where it is just laying in plain text.

Here is a blog post with some nice simple ideas.