views:

26

answers:

1

I have an app that uses a single-user OAUTH token. I can store the four values (consumer key/secret, token/secret) directly inside the app but that's not recommended and I don't want the secrets to be checked into source code. The app doesn't use a database. I know that however I store them, someone with access to the server could figure them out but I'd like to at least get it out of the source code. I've thought of passing them as Passenger environment variables or storing them in a separate file on the server but are there better ways? Is there any point to encrypting them since anyone that could see them would also have the access needed to decrypt?

A: 

Not having the keys stored in the source code actually is actually bad a practice in the accoding to the most agile setup (continuous deployment).

But, by what you say, you want to have two groups: those who can make the code, and those who can deploy it. Those who can deploy it have access to the keys, and, in the most secure setting, must NOT use the code of the application. You can make the oauth still work by having those who code autenticate to a system that proxies all the authorization part, and authenticates de application. Such keys (app -> auth middle man) can be in repository, as they are internal.

Any other setup: authentication library created by those who can deploy, encrypted keys, anything else can be broken by those who make the code. If you don't trust them enough to have access to the keys, you probably don't trust them enough not to try to jailbreak the keys.

The resulting deployment scheme is much more complicated, and, therefore much more prone to erros. But it is, otherwise, more secure. You still have to trust someone, like those who install the operating system, the proxy's system middleware, those who maintain the proxy's machine(s), those who can long on it, and so on. If the groupo of people with access to the keys is small enough, and you trust them, then you've gained security. Otherwise, you lost security, ability to respond to change, and wasted a lot of people's time.

Unfortunately, all authorization schemes require you to trust someone. No way around it. This is valid for any application/framework/authorization scheme, not only sinatra, rails, oauth, java, rsa signatures, elliptic curves, and so on.

Daniel Ribeiro
That's a good, thorough answer. In my case, the deployer (me) is the only developer so I'm just going to pass the keys via environment variables. If anyone gets access to the machine, I've got more problems than my OAUTH secrets.
Brian Deterling
If that is the case, you can limit the amount of danger you get into if the machine is compromised by requiring a password to decrypt every senstive data on the application startup. If the machine is compromised though, the attackers can change the application to tell them the password, and kill the application, forcing you to restart it (and therefore, give the password). Combined with intrusion detection tools, this is pretty much as safe as it gets. You will still trust your os, the middleware, the tools and the libraries, but, as I said, you have to trust someone, always.
Daniel Ribeiro