Software Engineering
project-management version-control development-process api
Updated Thu, 28 Jul 2022 03:09:47 GMT

Strategy for keeping secret info such as API keys out of source control?


I'm working on a website that will allow users to log in using OAuth credentials from the likes of Twitter, Google, etc. To do this, I have to register with these various providers and get a super-secret API key that I have to protect with pledges against various body parts. If my key gets ganked, the part gets yanked.

The API key has to travel with my source, as it is used at runtime to perform authentication requests. In my case, the key must exist within the application in a configuration file or within the code itself. That isn't a problem when I build and publish from a single machine. However, when we throw source control into the mix, things get more complicated.

As I'm a cheap bastard, I'd much prefer to use free source control services such as TFS in the cloud or GitHub. This leaves me with a slight conundrum:

How can I keep my body intact when my API keys are in my code, and my code is available in a public repository?

I can think of a number of ways to handle this, but none of them are that satisfying.

  • I could remove all private info from code, and edit it back in after deployment. This would be a severe pain to implement (I won't detail the many ways), and isn't an option.
  • I could encrypt it. But as I have to decrypt it, anyone with the source could figure out how to do so. Pointless.
  • I could pay for private source control. LOL j/k spend money? Please.
  • I could use language features to segregate sensitive info from the rest of my source and therefore keep it from source control. This is what I'm doing now, but it could easily be screwed up by mistakenly checking in the secret file.

I'm really looking for a guaranteed way to ensure I don't share my privates with the world (except on snapchat) that will work smoothly through development, debugging and deployment and be foolproof as well. This is completely unrealistic. So what realistically can I do?

Technical details: VS2012, C# 4.5, source control is either going to be TF service or GitHub. Currently using a partial class to split the sensitive keys off in a separate .cs file that won't be added to source control. I think GitHub may have the advantage as .gitignore could be used to ensure that partial class file isn't checked in, but I've screwed that up before. Am hoping for a "oh, common issue, this is how you do it" but I may have to settle for "that doesn't suck as much as it could have", :/

Solution

Don't put your secret information in your code. Put it into a configuration file which is read by your code at startup. Configuration files shouldn't be put on version control, unless they are the "factory defaults", and then they shouldn't have any private information.

See also the question Version control and personal configuration file for how to do this well.

Comments (5)

  • +8 – @RobertHarvey by just not putting it on version control, adding an ignore rule when necessary. Anyone using the software has to build their own configuration file with their own API key. — Jul 21, 2013 at 20:47  
  • +0 – So when you go to build and create a distribution of your software, how are you sure that it ships with a configuration file? Unless you have some file with reasonable defaults, it's usually not reasonable to expect your user to go through a process of making a configuration file. — Jul 21, 2013 at 21:13  
  • +4 – Well, factory defaults are one part, "installers" or "first run wizards" another one — Jul 21, 2013 at 21:56  
  • +6 – If many users have their own installation, shouldn't they create and use their own API key? Multiple sites/installs using the same key is probably a bad idea. If it's just one install, then using a configuration file is not a big hassle. — Jul 22, 2013 at 11:53  
  • +0 – @Will, if you can't do this because of the impracticality of implementation details, then I'd say you simply don't have the proper tooling for deployment. Deployment using a non-comitted secret config file should be completely painless. I can't offer specific advice to you since I live in the Ruby ecosystem, not C#. But Ruby people tend to use Capistrano for automated deploys. I'm sure C# has its tool for automated deployment as well, and this should make the process easy. — Jul 22, 2013 at 19:02  

Linked Articles

Local articles referenced by this article:

References