<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Bruno Pedro 💡</title>
    <description>The latest articles on Forem by Bruno Pedro 💡 (@bpedro).</description>
    <link>https://forem.com/bpedro</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F21271%2F8394b65c-9d05-417a-b60e-350490b86d38.jpeg</url>
      <title>Forem: Bruno Pedro 💡</title>
      <link>https://forem.com/bpedro</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/bpedro"/>
    <language>en</language>
    <item>
      <title>How to securely store API keys</title>
      <dc:creator>Bruno Pedro 💡</dc:creator>
      <pubDate>Thu, 26 Oct 2017 11:04:24 +0000</pubDate>
      <link>https://forem.com/bpedro/how-to-securely-store-api-keys-ab6</link>
      <guid>https://forem.com/bpedro/how-to-securely-store-api-keys-ab6</guid>
      <description>&lt;p&gt;In the past, I’ve seen many people use &lt;code&gt;git&lt;/code&gt; repositories to store sensitive information related to their projects. Lately, I’ve also been seeing some people even announce that they’re storing API keys on their private GitHub repositories. I’m writing this article because I believe that people should understand the risks of storing API keys with your code.&lt;/p&gt;

&lt;p&gt;This article is not intended to be read as a permanent solution to the problems you might have with storing API keys. Instead, it’s my own analysis of the problem and my suggestions on how to fix it. So, to begin with, what exactly is the problem with storing sensitive information near your code on a &lt;code&gt;git&lt;/code&gt; repository?&lt;/p&gt;

&lt;h2&gt;
  
  
  Why you shouldn’t store API keys on git repositories
&lt;/h2&gt;

&lt;p&gt;Storing API Keys, or any other sensitive information, on a &lt;code&gt;git&lt;/code&gt; repository is something to be avoided at all costs. Even if the repository is private, you should not see it as a safe place to store sensitive information. Let’s start by looking at why it’s a bad idea to store API keys on &lt;strong&gt;public&lt;/strong&gt; &lt;code&gt;git&lt;/code&gt; repositories.&lt;/p&gt;

&lt;p&gt;By nature, a public &lt;code&gt;git&lt;/code&gt; repository can be accessed by anyone. In other words, anyone with an Internet connection can access the contents of a public &lt;code&gt;git&lt;/code&gt; repository. Not only that, but they can also browse all the code inside the repository and possibly even run it. If you store an API key on a public repository, you are publishing in the open so that anyone can see it.&lt;/p&gt;

&lt;p&gt;A recent search for &lt;strong&gt;client_secret&lt;/strong&gt; on GitHub revealed that there are more than one 30,000 commits that potentially expose an API key and secret. In some cases, you can just copy and paste the code and immediately access the API.  This problem is becoming so important that some companies invest in resources to make sure that there aren’t any leaked API keys and secrets. Last year Slack started to search for exposed API tokens and invalidate them proactively. This action prevents malicious access to Slack’s accounts but can’t possibly find all the leaked tokens.&lt;/p&gt;

&lt;p&gt;So, this is happening on public &lt;code&gt;git&lt;/code&gt; repositories. What about the &lt;strong&gt;private&lt;/strong&gt; ones? Why is that an issue? Private &lt;code&gt;git&lt;/code&gt; repositories, especially those hosted on services such as GitHub, GitLab, and Bitbucket, are exposed to a different type of risk. Whenever you integrate a third-party application with one of the services mentioned before, you might be opening your private repositories to those third parties. Those applications will be able to access your private repositories and read the information contained therein. While that alone doesn’t create any risk, imagine if one of those applications becomes vulnerable to attackers. By getting unauthorized access to one of those third-party applications, attackers might gain access to your sensitive data, including API keys and secrets.&lt;/p&gt;

&lt;h2&gt;
  
  
  So, where should API keys be stored?
&lt;/h2&gt;

&lt;p&gt;Fortunately, there are many alternatives for securely storing API keys and secrets. Some of them let you use your &lt;code&gt;git&lt;/code&gt; repository and simply encrypt the sensitive data. Other tools are more sophisticated and automatically decrypt sensitive information as part of a deploy workflow. Let’s look at some of the available solutions.&lt;/p&gt;

&lt;h3&gt;
  
  
  &lt;code&gt;git-remote-gcrypt&lt;/code&gt;
&lt;/h3&gt;

&lt;p&gt;The first solution lets you encrypt a whole &lt;code&gt;git&lt;/code&gt; repository. &lt;a href="https://github.com/spwhitton/git-remote-gcrypt"&gt;&lt;code&gt;git-remote-gcrypt&lt;/code&gt;&lt;/a&gt; does that by adding functionality to &lt;code&gt;git&lt;/code&gt; remote helpers so that a new encrypted transport layer becomes available. Users simply have to set up a new encrypted remote and push code into it. Read on if you’re looking for a more fine-grained solution that lets you encrypt individual files.&lt;/p&gt;

&lt;h3&gt;
  
  
  &lt;code&gt;git-secret&lt;/code&gt;
&lt;/h3&gt;

&lt;p&gt;&lt;a href="http://git-secret.io/"&gt;&lt;code&gt;git-secret&lt;/code&gt;&lt;/a&gt; is a tool that works on your local machine and encrypts specific files before you push them to your repository. Behind the scenes, &lt;code&gt;git-secret&lt;/code&gt; is a shell script that uses &lt;code&gt;gpg&lt;/code&gt; to encrypt and decrypt files that might have sensitive information.&lt;/p&gt;

&lt;h3&gt;
  
  
  &lt;code&gt;git-crypt&lt;/code&gt;
&lt;/h3&gt;

&lt;p&gt;Another solution is &lt;a href="https://www.agwa.name/projects/git-crypt/"&gt;&lt;code&gt;git-crypt&lt;/code&gt;&lt;/a&gt;. It is very similar to &lt;code&gt;git-secret&lt;/code&gt; in the way it operates, but it has some interesting differences. The first thing to notice about &lt;code&gt;git-crypt&lt;/code&gt; is that it is a binary executable and not a shell script, as &lt;code&gt;git-secret&lt;/code&gt; is. Being a binary executable means that to use it you first have to compile it, or you need to find a binary distribution for your machine. If you’re using a Mac you’re lucky because HomeBrew offers a &lt;code&gt;git-crypt&lt;/code&gt; ready-to-install package—the only thing you have to do is run &lt;code&gt;brew install git-crypt&lt;/code&gt; on a terminal.&lt;/p&gt;

&lt;h3&gt;
  
  
  BlackBox
&lt;/h3&gt;

&lt;p&gt;&lt;a href="https://github.com/StackExchange/blackbox"&gt;BlackBox&lt;/a&gt; is a tool created by &lt;a href="https://stackoverflow.com/"&gt;Stack Overflow&lt;/a&gt;, the company behind popular Q&amp;amp;A communities such as Stack Overflow itself, Server Fault, and Super User. BlackBox is a quite robust tool as it works not only with &lt;code&gt;git&lt;/code&gt; but also with other version control systems like Mercurial, and Subversion. It also supports the encryption of small strings and not just entire files. It does that when working with &lt;a href="https://puppet.com/"&gt;puppet&lt;/a&gt; and uses puppet’s &lt;a href="https://docs.puppet.com/hiera/"&gt;hiera&lt;/a&gt;, a key-value lookup tool for configuration data. Having the ability to encrypt and decrypt individual strings makes BlackBox a great solution for securing API keys and secrets.&lt;/p&gt;

&lt;h3&gt;
  
  
  Heroku Configuration and Config Vars
&lt;/h3&gt;

&lt;p&gt;If you’re working with &lt;a href="https://www.heroku.com/"&gt;Heroku&lt;/a&gt; you should not store any sensitive information such as API keys and secrets on your &lt;code&gt;git&lt;/code&gt; repositories. Heroku itself offers a solution that lets you &lt;a href="https://devcenter.heroku.com/articles/config-vars"&gt;set configuration variables&lt;/a&gt;. Your application can then access the contents of those configuration variables during runtime by accessing the corresponding environment variables. Even though the values are not encrypted, this solution lets you avoid using your &lt;code&gt;git&lt;/code&gt; repository for storing API keys. &lt;a href="http://dokku.viewdocs.io/dokku/"&gt;Dokku&lt;/a&gt;, which is an Open Source solution similar to Heroku, offers the same capabilities.&lt;/p&gt;

&lt;h3&gt;
  
  
  Docker secrets
&lt;/h3&gt;

&lt;p&gt;At the end of the spectrum of possible solutions is &lt;a href="https://docs.docker.com/engine/swarm/secrets/"&gt;Docker secrets&lt;/a&gt;. This solution &lt;a href="https://blog.docker.com/2017/02/docker-secrets-management/"&gt;has been introduced by Docker&lt;/a&gt; in February 2017 and is gaining popularity ever since. Docker secrets let you define variables that are encrypted and made available to specific services during runtime. Secrets are encrypted both during transit and at rest. This approach makes Docker secrets the perfect solution for storing and using API keys and secrets in a secure and encrypted way.&lt;/p&gt;

&lt;h2&gt;
  
  
  Summary
&lt;/h2&gt;

&lt;p&gt;By now you should be aware of the dangers of storing sensitive information such as API keys and secrets on public and also private &lt;code&gt;git&lt;/code&gt; repositories. Understanding the potential ways in which your repositories might be exposed is key to assessing and mitigating the risks associated with information leaks. This article also proposes a few different solutions that let you encrypt API keys and secrets so that you can securely use your code repositories. I’m sure there are more solutions out there that can help you achieve the same results.&lt;/p&gt;

</description>
      <category>git</category>
      <category>api</category>
      <category>security</category>
      <category>encryption</category>
    </item>
  </channel>
</rss>
