paint-brush
All The Secrets Of Encrypting API Keys In Ruby Revealedby@jamezjaz
708 reads
708 reads

All The Secrets Of Encrypting API Keys In Ruby Revealed

by James Chigozie OdufuSeptember 27th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

This article is for those who have worked with API keys in Ruby or those who tend to do so. The dangers of leaving API keys hardcoded on our applications and/or projects built with Ruby are discussed below. API keys are like the keys to your house or your car, therefore, it's important to protect them to make sure they can only be used by the people and in the way you want. To help keep your API keys secure, follow these best practices: Do not embed API keys directly in code. Store them in environment variables or in files outside of your application's source tree.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - All The Secrets Of Encrypting API Keys In Ruby Revealed
James Chigozie Odufu HackerNoon profile picture

This article is for the interest of those who have worked with API keys in Ruby or those who tend to do so. Devs who worked or who intend to work API keys in other languages may also benefit from this article.

First and foremost, I’d like to explain the meaning of API and hard coding:

API simply put as Application Programming Interface (API), is a toolset that programmers employ in software creation. A good example is the Apple (iOS) API that's used to detect touchscreen interactions. APIs are sets of functions that allow applications to access data and interact with external software components, and operating systems.

Hard coding is the software development practice of embedding data directly into the source code of a program or other executable objects, as opposed to obtaining the data from external sources or generating it at runtime.

Hence, hard coding API keys is simply the practice of embedding API keys directly into the source code of our applications or programs.

And by Encrypting API keys, I mean making them hidden and secure.

The dangers of leaving API keys hardcoded on our applications and/or projects built with Ruby are discussed below:

One of the many reasons why it’s completely improper to have API keys hardcoded on our applications and/or projects is;

One way that developers inadvertently expose their API keys is to hard-code them directly into the source code of their applications. For this reason, hard-coding keys from any API provider directly into the source code of their apps are widely considered to be a security flaw across the API, security, and developer communities. This is simply because it exposes one’s programs and its contents to security threats. Such programs or applications, its contents, and/or features are exposed to hackers and to everyone else whose intent is to gain unauthorized access and cause malicious damage to the apps or its contents.

Publicly exposing your API keys can result in your account being compromised, which could lead to unexpected charges on your account.

API keys are like the keys to your house or your car, therefore, it's important to protect them to make sure they can only be used by the people and in the way you want.

How Do I Protect My API Keys

Note the following steps:

Securing an API key

When you use API keys in your applications, ensure that they are kept secure during both storage and transmission. Publicly exposing your credentials can result in your account being compromised, which could lead to unexpected charges on your account. To help keep your API keys secure, follow these best practices:

  • Do not embed API keys directly in code. API keys that are embedded in code can be accidentally exposed to the public. For example, you may forget to remove the keys from the code that you share. Instead of embedding your API keys in your applications, store them in environment variables or in files outside of your application's source tree.
  • Do not store API keys in files inside your application's source tree. If you store API keys in files, keep the files outside your application's source tree to help ensure your keys do not end up in your source code control system. This is particularly important if you use a public source code management system such as GitHub, GitLab, etc.
  • Set up application and API key restrictions. By adding restrictions, you can reduce the impact of a compromised API key.
  • Delete unneeded API keys to minimize exposure to attacks.
  • Regenerate your API keys periodically. Then, update your applications to use the newly-generated keys. Your old keys will continue to work for 24 hours after you generate replacement keys.
  • Review your code before publicly releasing it. Ensure that your code does not contain API keys or any other private information before you make your code publicly available.
  • Where possible, employ a Senior Dev or a code Reviewer to review your code(s) before you public.

HOW TO ENCRYPT API KEYS IN RUBY

Certainly, there is more than one way to achieve this purpose but the method below works out fine.

Here, I’m going to tell us how to encrypt API keys using dotenv gem.

API KEYS ENCRYPTION, RUBY

1. Create a file on your root directory called token.env

2. Inside the file, create the variable TOKEN = "the-token-string-you-have-on-your-file".

Example;

TOKEN = 'xxxxxxxx:AAABBBc7bgHH8844hiug_0n_j6ug'

NB: The above token is just a sample token :)

3. Install the gem using

gem install dotenv

4. In your main.rb file (or the one where you use the token), use this:

require 'dotenv'
Dotenv.load('token.env')

Please, pay attention to the highlighted area.

5. Then, when you want to use the variable, do it like this:

token  = ENV['TOKEN']

I've used the gem a good number of times, so if you follow my instructions, everything should work out fine.

I know you will be able to make it work with that base. Remember, the TOKEN variable needs to have the value of the actual token inside.

6. Then add token.env in gitignore and that’s it.

This would ensure the whole process aren't uploaded on any public source code management system or version control system such as GitHub, GitLab, etc.

For questions, suggestions, and contributions, reach me out on…

LinkedIn Twitter GitHub [email protected]