Search
Encryption
Encrypted Credentials on Rails 5.2: Secrets to Success
Edit
#ruby-on-rails
#security
#deployment
#encryption
Summarized using AI

Encrypted Credentials on Rails 5.2: Secrets to Success

Christopher Rigor • May 17, 2018 • Pittsburgh, PA • Talk

The video, titled "Encrypted Credentials on Rails 5.2: Secrets to Success," features Christopher Rigor discussing the advantages of encrypted credentials introduced in Rails 5.2, taking place at RailsConf 2018. Rigor, a tech evangelist at Engine Yard, elaborates on the shortcomings of the previous approaches to managing secrets in Rails applications and outlines the streamlined process that encrypted credentials provide.

Key Points Discussed:

- Introduction of Encrypted Credentials:

- Rails 5.2 offers a refined approach to managing secrets compared to Rails 5.1’s encrypted secrets, which have been deprecated.

- Encrypted credentials allow for atomic deploys and eliminate sensitive data exposure through environment variables.

  • Setup Process:

    • When a new Rails application is created, Rails generates a master key and secrets automatically using the command rails credentials:setup.
    • Developers can manage credentials with rails credentials:edit, allowing them to securely edit configurations without exposing sensitive information.

  • Editing and Accessing Credentials:

    • Encrypted credentials are nested per environment and allow developers to access sensitive information using Rails.application.credentials.
    • The built-in command rails credentials:show can display the credentials, emphasizing that they should not be displayed in views or front-end code directly.

  • Demonstration of APIs and Encryption:

    • Rigor demonstrates using encrypted configuration APIs provided by Rails for custom encrypted data handling beyond standard credentials.
    • The underlying encryption is based on Advanced Encryption Standard (AES), a symmetric cipher known for its security and industry-wide acceptance.

  • Comparison to Previous Methods:

    • The discussion touches on previous secret management strategies, highlighting the risks associated with using environment variables and unencrypted files.
    • The history and inadequacies of the Data Encryption Standard (DES) are brought up to explain the necessity for robust encryption methods like AES.

  • Alternatives and Future Considerations:

    • Rigor addresses the importance of assessing existing credential management practices and suggests considering encrypted credentials if no secure method is currently in use.
    • The talk mentions actively ongoing discussions and potential future updates for handling per-environment credentials more effectively that could enhance the Rails ecosystem further.

Conclusions/Takeaways:

- Encrypted credentials in Rails 5.2 significantly improve the security and management of sensitive application data, and they are recommended for developers yet to adopt encryption.

- Staying informed about best practices and proposed features can be crucial as the Rails framework evolves.

- The importance of keeping credentials secure while simplifying access is the core message of the talk, ensuring developers implement these features appropriately without compromising security.

Encrypted Credentials on Rails 5.2: Secrets to Success
Christopher Rigor • May 17, 2018 • Pittsburgh, PA • Talk

RailsConf 2018: Encrypted Credentials on Rails 5.2: Secrets to Success by Christopher Rigor

Secrets are out. Credentials are in. This new Rails 5.2 feature offers a number of advantages over the old way of managing secrets. You get atomic deploys, you avoid putting sensitive data on environment variables, and your data is always encrypted.

This talk will reveal the secrets to success in using Credentials and EncryptedConfiguration, the API it uses internally.

This is a sponsored talk by Engine Yard.

RailsConf 2018

00:00:10 Welcome to Encrypted Credentials on Rails 5.2: Secrets to Success. This is a sponsored talk by Engine Yard.
00:00:19 In January, we'll discuss everything you need to deploy a Rails app in production. We've been around for 10 years, providing 24/7 support, including DBA support.
00:00:30 You don't have to wait three months for your app to fail; we can proactively help you with that. You'll also receive AWS support through us. If you have any questions, come talk to me or the Engine Yard team. We'll have a booth tomorrow and Thursday.
00:00:49 My name is Christopher Rigor, and I'm the tech evangelist at Engine Yard. You can find me on Twitter @Krieger.
00:01:01 So, who here has already used credentials on Rails 5.2? Okay, we have a few people. That's more than I expected.
00:01:11 If everyone is using Rails 5.2 and credentials, then we might not need to have this talk, but that's good. How about encrypted secrets on Rails 5.1? A few hands go up.
00:01:24 The good news is you're encrypting your data. The bad news is it's already deprecated. From Rails 5.1 to 5.2, they introduced encrypted secrets and then deprecated them.
00:01:36 You can still use it; I'm not sure when they'll remove it in Rails 6. But, yeah, secrets were introduced in Rails 4.1 and up.
00:01:48 I see some people raise their hands, indicating they're using Rails 3. So, let's take a look at what secrets were in the channel.
00:02:10 Every time you create a new Rails application, you get secrets grouped by environment: development, test, and production. In development and test, the secret key base is hard-coded, but in production, you read that from an environment variable.
00:02:31 We do this because you can commit this file to your repository. That's why you don't want to put any credentials in that file; everyone with access to your repository would see it.
00:02:44 The problem here is that, while the secret key base is fine for development, if you have AWS keys, even if you're using them just for development, you don't want others to access them.
00:03:03 So, what you do is keep using environment variables. Before you know it, you have many environment variables in this file. A lot of people have been using this workaround, but you just have to remember to set your environment variables securely.
00:03:24 There are some gems that help with that, but we want to move to something better. In Rails 5.1, it was duplicated, but we'll discuss that in a moment.
00:03:41 This is the first time that Rails has been encrypting data and helping you encrypt your data. Previously, you could use some gems, but now you can do it out of the box.
00:03:52 When you want to use encrypted secrets, you run the command 'secret setup,' which creates a key for your application and also creates a secrets file that you could commit to the repository.
00:04:10 But you shouldn't put the key in your repository because if someone has both the key and the encrypted file, they can decrypt it.
00:04:36 So, when you edit your credentials, you actually use the command 'secrets edit.' You won't be able to just open the file and edit it directly. This command encrypts your data, puts it into a temporary file, and then opens your text editor.
00:04:59 That's why you have to set the environment variable for your editor if you haven't. You would see something like this, and the command is 'secrets.yaml' for generating suitable keys.
00:05:18 You would see here that it's still grouped by environment. You have the production environment and the API keys. The problem is that you're using secrets.yaml for some credentials, and they're not encrypted.
00:05:35 Then you have encrypted secrets, which are encrypted. So you have two different files: one is encrypted, and one is not. It gets confusing.
00:05:44 That's why even though it was introduced recently, it was already deprecated. Looking at the encrypted file, you can commit this to your repository because no one would get your data if they don't have your key.
00:06:01 This means you wouldn't be able to access the data because you wouldn't understand it.
00:06:14 Instead of using 'secrets' and 'encrypted secrets,' they changed the name to 'credentials.'
00:06:25 So 'credentials' is used in Rails 5.2. You get a key named 'master key' or you could set it with an environment variable, named 'RAILS_MASTER_KEY.'
00:06:41 This title, 'Encrypted Credentials', suggests that there are unencrypted credentials, which is incorrect. So we use credentials, and they're always encrypted.
00:06:54 When using it, similar to Rails 5.1 encrypted secrets, you run 'credentials edit.' You would see that you didn't run any setup code because if you create a new Rails 5.2 application, you would automatically get a key.
00:07:02 But if you're upgrading, you could also run a setup command that will generate the key for you. When you run this, you would get something like this.
00:07:29 What has changed here? You would see that it is not grouped by environment anymore; there’s no development or production.
00:07:41 Your secret key base automatically gets added to it. There's no separate secrets.yaml; it doesn't get generated anymore in Rails 5.2. You're supposed to use this only in production.
00:08:02 For development or staging, we'll discuss that towards the end of the talk. Now, I want to give a demo on how to use credentials.
00:08:17 Can everyone see that okay? Now, I'm creating a new application, and it finished quickly. We're starting with a brand new Rails 5.2 application.
00:08:34 If you search for 'master key,' you would see that Rails automatically creates that file over there. Let's generate a controller that we’ll use later, right, and the Welcome action.
00:08:56 We see here that it's a standard generator that creates the files. Now, we would edit the credentials, so the master key has been created automatically.
00:09:07 Now we want to use those credentials, so let's set our editor and then run 'rails credentials edit.' The AWS key is actually commented out.
00:09:28 So we'll uncomment that. I heard DHH doesn't like the 'foo' variable, so we’ll change that. Now, let’s save it.
00:09:49 Okay, so it's fast here. New credentials, encrypted and saved. Once you save your text editor, it encrypts those credentials and saves it.
00:10:08 If you check, for example, for your 'credentials.yaml,' it is encrypted. Your unencrypted credentials, the ones you saw earlier, won't be saved in your application.
00:10:22 Okay, so let's go to our application.
00:10:28 This is our application. Let's view the routes; I'm using a Mac, running it on my local machine.
00:10:36 Now let’s edit the Welcome view, making it say 'Hello, RailsConf!' This might be the most controversial part of the talk: using inline CSS style for the font size.
00:10:54 So how do we access our credentials? You access them with 'Rails.application.credentials'.
00:11:05 And that's it! You can access your credentials with that. Then 'AWS_ACCESS_KEY_ID' is 'Rails.application.credentials.AWS'.
00:11:20 Since it's nested in the YAML file, it will turn into a hash when accessed.
00:11:34 Now let's run it. Okay, it’s running. Let's go to the application. That looks ugly; forgot the new line. But yeah, our AWS access key ID is 123.
00:12:05 So that's how you access the credentials from your application. What did we learn here? Well, first: don’t use inline CSS, and don’t display your credentials on your view.
00:12:23 This is just a demo. Don’t just display your credentials to see them.
00:12:34 There's actually a command to display your credentials, which is 'rails credentials:show.' You can do that.
00:12:46 So that’s the demo for using the encrypted credentials. If you noticed, I ran 'rails new,' and then I ran 'rails credentials:show.' This is not on my laptop.
00:12:56 If you can see, I've included spaces. This is one of the tools that we were experimenting with at Engine Yard, which is running your Rails application on a remote server.
00:13:15 It's nothing new; people have done it. If I'm on the conference Wi-Fi and I attempted to start from a new Rails application, it connects to rubygems.org.
00:13:34 But it's on a remote server. So what's new with Dev Spaces? We're trying to use local IDEs.
00:13:45 One of the challenges of using just servers is that I had to use vim or SSH into a server. But here I’m using my local IDE.
00:14:04 It has my shortcuts and customizations, and I don't have to install Ruby, Rails, or connect to RubyGems from my machine.
00:14:22 I can continue using my local IDE. Cloud IDEs were a fad before, but I am sticking to my IDE.
00:14:41 If you use Visual Studio Code, you can continue using that; it's great.
00:14:50 If you want to learn more about Dev Spaces, stop by the booth; it's great for developers, especially when traveling.
00:15:03 The next part of the demo is to see how the encryption works that Rails uses on your own code.
00:15:29 Rails didn’t just say to use this for credentials—they exposed the API. If you want to use it in your own app, you don’t have to rewrite things. You can just use whatever it’s using.
00:15:53 On a Rails console, for example, the credentials return an encrypted configuration. This is the new class Rails added and exposed for you.
00:16:12 You could use encrypted configuration, but instead of using credentials, you actually use 'Rails.application.credentials' and now you want to specify the file you wish to encrypt.
00:16:30 Instead of using the 'credentials.yaml' that Rails uses, I want to encrypt something else, say 'railsconf.yaml'.
00:16:43 So I can write my code and encrypt it, creating a new encrypted file. You’d see that you have 'railsconf.enc'.
00:17:02 Again, it's encrypted, similar to 'credentials.yaml.' You can't see it; you need to run a command to decrypt it.
00:17:15 We didn't specify any key here, so what key did it use? It reused the master key that Rails already created.
00:17:27 If this is something you don’t want to do because you want to use a separate key for another purpose, Rails supports that too.
00:17:41 If you want to use a new key, generate the key first with 'encrypted_configuration:generate_key.' Now you get this new key.
00:17:57 It’s just a hex of size 32; you need 16 bytes for the key. So the hex string will be of length 32.
00:18:16 You didn’t have to do this earlier because Rails already generates it for you. Let’s insert this key and call it the top-secret key.
00:18:33 This key will encrypt my data. I want to use a separate key instead of reusing my master key.
00:18:45 So, this key can be created on my local machine, and now it’s on the Dev Space.
00:19:02 Now I can use 'Rails.application.encrypted_config.top_secret' to specify the key. Instead of using the master key file, I can specify any key that I want.
00:19:18 Let’s write, you know, 'This is a top-secret message.' Earlier I told you I could edit that as well. Instead of using 'credentials edit,' Rails gives us 'encrypted edit.'
00:19:37 So I specify 'top_secret.enc' and pass the key I want to use because I’m using a different key: the top-secret key.
00:19:50 Now you get an editor again with the message that you want to edit, and you could also do 'encrypted show,' which is similar to credentials show.
00:20:09 You won’t need the editor variable there, but you can see your encrypted message.
00:20:22 So, that is the demo for encrypted credentials. What does encrypted configuration use?
00:20:40 Encrypted configuration is the new class used in Rails, which utilizes the 'message_encrypter.' If you’ve heard of this, it was introduced in Rails 4.1, used for encrypting data in cookies.
00:20:57 Rails has exposed a new class, but underneath, it reuses what’s already working well for us.
00:21:14 So, what type of encryption do we use? The cipher we use is AES, which is a symmetric cipher.
00:21:28 We won’t delve into details about how it works, as DHH mentioned, we let someone else handle it.
00:21:41 AES is a symmetric cipher and can either be a stream or block cipher. A stream cipher encrypts data individually, whilst a block cipher divides data into blocks.
00:21:54 AES is a block cipher. But before we talk more about AES, let’s discuss what came before it: DES, or Data Encryption Standard.
00:22:09 This was released in 1977 by the National Institute of Standards and Technology (NIST).
00:22:25 This is the agency that provides guidelines for passwords and other cryptography standards. DES was developed by IBM with assistance from the NSA.
00:22:42 There were concerns that the NSA could have implemented a backdoor in DES. Some parts of the algorithm weren’t fully described.
00:23:02 DES and other block ciphers use substitution boxes. DES uses eight of these S-boxes, which have specific hard-coded values.
00:23:14 When people learned that those numbers were chosen without significant explanation, concerns arose that they were potentially a backdoor.
00:23:38 In 1992, researchers released a paper on an attack known as differential cryptanalysis, which targeted block ciphers, including DES.
00:23:56 However, it was noted that this attack wasn’t particularly effective against DES. One of the creators of DES acknowledged that they were aware of cryptanalysis attacks.
00:24:15 In the 1990s, DES was coming under attack. With advanced hardware, computers were built specifically to exploit weaknesses in DES.
00:24:34 The issue with DES was its small key size of 56 bits, which was deemed insufficient. While IBM had aimed for a 128-bit key, the NSA insisted on 56 bits.
00:24:58 In response, NIST sought a new cipher to replace DES.
00:25:09 Rather than develop a standard as with DES, they opened submissions for a new cipher.
00:25:25 In 1999, five finalists were selected, leading to the choice of the Rijndael cipher, which was later renamed to AES.
00:25:44 AES is notable for its open development process and is widely regarded as the encryption standard. Many applications, including those used by government agencies, utilize AES.
00:26:06 128-bit keys are standard. Recommendations for RSA keys lean towards larger sizes, such as 2048 bits, but with AES, key sizes can be 128, 192, or 256 bits.
00:26:26 A common question is whether to use credentials.
00:26:38 If you haven’t been encrypting your data, it’s advisable to start using credentials.
00:26:53 If you have existing policies to manage your environment, it’s important not to mix staging and production keys.
00:27:06 Check what you’re currently using and evaluate if the new feature is better for you.
00:27:22 Alternatives include EG configuration from Shopify, which utilizes JSON, but they recently labeled it as abandoned.
00:27:35 You may also explore encrypted secrets, which served as inspiration for the credentials feature.
00:27:49 Regarding the discussion on development, staging, and test credentials, there is still an open pull request.
00:28:01 The Rails core team has yet to provide a definitive solution. It's an ongoing conversation.
00:28:14 Last I checked, there were many engaging discussions on this topic.
00:28:28 As a final note, feel free to check on the status of upcoming features.
00:28:42 Thank you for listening, and now we have time for questions.
Christopher Rigor
@crigor
Explore all talks recorded at RailsConf 2018
+103