(Not so) Stupid Question 326: Should I avoid storing passwords and secrets in version control?

I’m back! Today is the last day of my summer vacation and tomorrow its back to work. I’m excited and eager to start work again, and that’s a good indication that I have an awesome workplace! I’ve spent the last few weeks in the Norwegian mountains and in south of Sweden, as well as training for my first triathlon. I’ve tried to avoid the computer, my email and spent less time on social media (I even started painting again!) and I feel great! However, I kept up with my Stupid Question of the Day videos and posts, and I have a few lined up. Since I’ve been away, I haven’t posted on my blog, but I did record the first video on my first day and published it on YouTube. If you haven’t seen it, or prefer text, here is the write-up.

Watch the video here:

Earlier this year I noticed some private keys that had been checked in to our remote repository on GitHub. It wasn’t particularly sensitive information as it was local keys, but it started a discussion. I bet most developers, have at some point, accidentally checked in passwords or private keys (or other sensitive information in version control). In addition, some people don’t consider it a bad practice, and even see some benefits. As you probably have figured out by my wording, I’m not a big fan. So, if you asked me if you should store this information in version control (assuming private repositories with limited access) my reply would be a solid no. I did a poll on Twitter with 739 votes, and 17% had often done it, 52% replied ‘Yes, rarely’, 27% never, and 7% wasn’t sure.

But, let’s get back to why I’m not a big fan. First of all, it’s just a really bad habit. Even if the repository is private, and you are the only one with access, you still shouldn’t do it. It becomes a habit, and its easy to think that you’ll just do it once- as its convenient and you don’t have to set things up locally to modify config files and add files to the ignore list. Once it’s in source control, and keep in mind that most people reuse passwords so once it ends up somewhere else you can end up with more problems than you initially thought, the sensitive information can accidentally become accessible in several ways. If the repository is made public, or forked and then the fork is public, when collaborators are added, or once you (and others) start cloning the repo. If the sensitive information gets removed in a commit, it’ll still be there- hidden in plain sight. Not knowing if the information will make its way into a new branch or fork it can, again, be made public by accident. I know some people argue that it’s nice to track changes, but I don’t see the value in restoring an older version of the code, with a password that doesn’t work anymore (assuming it was changed). You would still have to update the config file, and if you don’t have a system in place for editing the configuration file (or whatever file you use for the information) then you are back to square one. Storing the information encrypted means that you still need a key to decrypt, and if that key is stored in the same source code- well, then you still have the information accessible. If the key is only stored locally, then why not store the sensitive information locally?

My final argument is that I generally like to keep development and deployment separate. Even if the deployment scripts are checked in, I would still keep them in a separate repository.

Our setup at work is as following:

Connection strings, passwords and keys are accessed through either environment variables or configuration. Each developer has a configuration file with their own data locally for testing purposes, and this file overrides the source-controlled configuration file when built, but is never checked in to source control. Optionally, the various config items can be set as environment variables. The code always checks the environment variables first, looking for a match, and if it doesn’t find one it will search the config file. During deployment, which is done on our build server on a limited access VPN, the deployment service (Octopus Deploy) updates the config files with the encrypted variables, and additionally the config file is encrypted. The config file is however never made public, and we monitor access to our VM’s, and the services are only accessed through a proxy and our proxy APIs.

When we hosted most our services on Azure, we were looking to use Azure Key Vault as I like the idea to have one place to manage everything, and to be able to easily revoke keys etc. But at the moment our current setup works well, is secure, and doesn’t have additional costs associated with it. There are other setups, and many options, and I’m sure ours can be improved. What is your setup?

(Not so) Stupid Question 326: Should I avoid storing passwords and secrets in version control?

Comments