 to encrypted credentials in Rails 5.2, secrets to success. So this is a sponsored talk by EngineYard. EngineYard is everything you need to deploy your Rails app in production. We've been around for 10 years. We provide 24-7 support. We provide DBA support. You don't have to wait three months for your app to fail. We could proactively help you with that. You also get AWS support through us. So if you have any questions, come talk to me. Come talk to the EngineYard team and we'll have a booth tomorrow and on Thursday. My name is Christopher Rieger. I'm the tech evangelist at EngineYard and you could find me on Twitter at Krieger. So who here has already used credentials on Rails 5.2? Okay, we have a few. I mean, that's more than what I expected. If everyone's using Rails 5.2 and credentials, then we don't need to have this talk. But yeah, so that's good. How about encrypted secrets on Rails 5.1? Okay, we have two. So the good news is you're encrypting your data. The bad news is it's already deprecated. So from 5.1 to 5.2, they introduced encrypted secrets, then deprecated it. You could still use it. I'm not sure when they'll remove it, Rails 6. But yeah. And then, secrets.caml, Rails 4.1 and up, I guess most of you are using that. I see some people who didn't raise their hands are using Rails 3.2. Yeah, one. We have one guy over there. So yeah, so let's take a look at what secrets.caml are. So every time you create a new Rails application, you get this, your secrets are grouped per environment, right? You have development, test, and production. So you would see on development and test, the secret key base are hardcoded. But in production, you read that from an environment variable. So why do we do that? Because you could commit this file to your repository. So that's why you don't want to put any credentials on that file because everyone who has access to your repo would see it. So the problem here is, well, secret key base, if you're only using it for development, it's fine if some people would see it. But if you have, let's say, AWS keys, even if you're using it just for development, you don't want other people to access it, right? So what you do is keep on using environment variables and before you know it, you have a lot of environment variables on this file, which is, we could work around that. That's what a lot of people have been using, but you just have to remember to set your environment variables and to do it securely. And there are some gems that help with that, but we want to move to something better, right? So on Rails 5.1, it is deprecated, but we'll talk about that a little bit. This is the first time that Rails is encrypting the data, or is helping you encrypt your data. So before you could use some gems, but now you could use it out of the box. So when you want to use encrypted secrets, you run secret setup, and that would create a key on your application, and then it would also create the secrets.yaml.enc. That one, you could commit to the repo, but the key you don't have, or you shouldn't put that in your repo, because if you have the key and the encrypted file, then anyone could just decrypt it. So this is what, so when you edit your credentials, you actually use secrets, edit a command. You won't be able to just open the file and then edit it yourself. What this command does is decrypt your data, put it into a temporary file, and then open your text editor. That's why you have to set the variable editor there if you haven't, and you would see something like this, and then the comment is, see secrets.yaml.tips on generating suitable keys. So you would see here that it's still grouped per environment, you have the production environment, and you have the key external API key. So the problem here is you're using secrets.yaml for some credentials, but they're not encrypted. Then you have encrypted secrets, which are encrypted. So you have two different files, one is encrypted, one is not, it gets confusing, right? So that's why even though it was introduced just recently, it was already deprecated. So this is just a look at the encrypted files. So that's why you could commit this to your repository because no one would get your data from here. If you don't have your key, this would just be, you won't be able to get the data from here, you won't understand it, right? So instead of using secrets and encrypted secrets, they changed the name to credentials. So credentials is used on Rails 5.2. You get a key named master.t or you could set it with an environment variable Rails master key. So I named this title encrypted credentials, which kind of suggests that there's an unencrypted credentials, which is wrong. So we just use credentials and they're always encrypted. So when using it, you, similar to Rails 5.1 encrypted secrets, you run credentials edit. So you would see here that you didn't write, you didn't run any setup code because if you create a new Rails 5.2 application, you would automatically get a key. So but if you're upgrading, you could also run a setup command that would generate the key for you. So now if you run this, you would get something like this. So what has changed here, right? You would see here that it's not group per environment anymore. There's no development or production. And then your secret key base automatically gets added to it, right? So there's no separate secrets that YAML, it doesn't get generated anymore on Rails 5.2. And yeah, you're supposed to use this only in production. For development or staging, we'll talk about that towards the end of the talk. So now I wanna, I want to do some demo on how it's done, how to use credentials, okay. So can everyone see that? So now I'm creating a new application and it finished quickly. So we're starting from a brand new Rails 5.2. application and if you search for master.key, you would see that Rails automatically creates that file over there. So then let's generate a controller that we'll use later and the welcome action. So we'd see here it's a standard generator with create files and now we would edit the credentials. So the master key has been created automatically and now we just want to use those credentials. So let's set our editor and then Rails credentials edit. Right, okay, so AWS is actually commented out so we'll uncomment that and then I heard DHH doesn't like the full variable so we'll put that in, right, and save it. Okay, so it says here new credentials encrypted and saved. So once you save your, on your text editor, it would encrypt those credentials and save it, right. So if you check, for example, for your credentials that camel.enc, that is encrypted, right. So your unencrypted credentials, the one that you saw earlier, won't be saved on your application. Okay, so let's go to, let's go to our application. So this is our application, let's view the routes. So I'm using a Mac Vim on my local machine, root pages, welcome, just so that we see that. And then let's edit the welcome view. So like hello, Railscon, and then let's, probably the most controversial in this talk, we'll use inline CSS style, font size. Yeah, I miss doing this. So who is, how do we access our credentials? So you access it with Rails application, that credentials, that poof. And that's it, you could access your credentials with that. And then AWS access key ID is Rails that application, that credentials, that AWS. And since it's nested on, you know, our YAML file is nested, this becomes a hash, so we'll access the, we'll use the access key ID key, right? And then, thank you, always make that mistake, okay. I closed my HTML tag, and then let's run Rails server. Okay, it's running, let's go to the app. Oops, that's actually the demo. All right, forgot the new line, but yeah, foo is bar, AWS access key ID is 123, right? So that's how you access the credentials from the YAML, so what did we learn here, right? Well first, don't use inline CSS, and don't display your credentials on your view, right? So this is just a demo, like don't go and say, well, you know, just display your credentials so we could see it, right? There's actually a way to display the credentials, which is Rails credentials, it could do that. So that's the demo for using the simple credentials, right? If you've noticed, I run Rails new, I run Rails credentials show, that's actually not on my laptop, if you could see I put there dev spaces. This is actually one of the tools that we're looking at, that we're trying at Engine Yard, which is running your Rails application on a remote server, right? Which is nothing new, right? I mean, people do it. If I'm on the conference Wi-Fi, and I attempted to start from a new Rails application, it connected to rubygems.org and all that, but it's on a remote server somewhere, so that's why I could do that. But what's new with dev spaces that we're trying, if you've noticed, I used my local IDE. So one of the problems with just using the server is, well, I have to use Vim or, I don't know, I just use Vim when I'm SSH to a server, but here I'm using my local IDE, which is also Mac Vim, but it has my shortcuts, I can keep in using it. So I didn't have to install ruby or Rails, or run or connect to rubygems.org for my machine. It does that from the remote server, but then I could continue using my local IDE. So cloud IDEs were a fad before, but here I'll use this because I like my IDE, I like my customizations. If you're using Visual Studio Code, just keep on using that, Sublime, Atom, you could continue using that. So yeah, if you want to learn more about dev spaces, we could approach us at the booth. It's great for developers, especially for me when I'm traveling, when the Wi-Fi is not great. Yeah. So the next part of the demo is using the encryption that Rails uses on your own code. So Rails didn't just say here use this for credentials, it exposed the API so that you could use it on your own app so that if you want to use encryption, you don't have to rewrite things, you could just use whatever it's using. So on a Rails console, you could see, for example, that credentials, these returns encrypted configuration. So this is the new class that Rails added and exposed for you, right? So you could use encrypted configuration, but instead of using that, let's just use it again, instead of using credentials, you actually use Rails that application that encrypted. And now I want to specify the file that I want. So I'm not using the credentials that the channel that the ENC that Rails uses, I want to encrypt something else. So I'm going to specify, let's say, Railscon for that ENC, right? Now I could write my code, my message, right? Hello Railscon, right? And if you read it, you could see it back. And that's how you create another encrypted file. So if you go here, you could see that you have Railscon ENC, right? So again, it's encrypted. It's similar to credentials that the channel that ENC, you can't see it, you need to run, you could use it from your app to decrypt it or you could also use it, use a command to decrypt it. We shall show in a bit. We didn't specify any key here, right? So what key did it use? It reused the master.key that Rails already created. So if that's something that you don't want to do because you want to use a separate key for a different purpose, you could do that as well and Rails support that as well. So if you, so we want to use a new key, right? So we generate the key first, encrypted, configuration, generate key. So now you get this new key that you could use, right? It's just a hex of size 32 because you need 16 bytes for the key. So the hex, the string is a length 32 that generate key uses, right? So you didn't have to do this earlier because Rails already generates it for us, right? But so let's insert here, let's call it the top secret key. So I'm going to save that and now this, I'll use this key to encrypt my data so that I don't want to reuse my master key. So, okay, top secret, right? So it's on my dev space now, I created it on my local machine on MacVim and then it's now on dev space, right? So I could now do bar, Rails, that application, that encrypted, config, top secret, enc. Now I could specify the key, right? So instead of using the master.key file, I could specify any key that I want. So I named it config, top secret key, right? There you go, and then you could write, this is a top secret message. So earlier I told you I could edit that as well. So instead of using credentials edit, Rails gives us encrypted edit, right? So you specify top secret, that enc, and then you pass the key that you want to use because you use a different key. So top secret, and you get an editor again with the message that you, so I added the message on my Rails console, edited it from the command line, then you could edit this and say, and then I could actually do encrypted show, which is similar to credentials show, and it was just, well, you don't need the editor variable there, but that just, you get the message. You see your encrypted message again. So yeah, that is the demo for encrypted credentials. Okay, so what does encrypted configuration use, right? So encrypted configuration is the new class that Rails uses, but it actually uses message encryptor. So if you've heard of this, this was actually introduced in Rails 4.1, which is used for encrypting data on your cookies. So it's, Rails exposed a new class, but inside it, it reuses what we've already been using. So that's one good thing about Rails, you were building things on top of what already works for us. So now on to what does credentials use, I mean what type of encryption that we use. The Cypher that Rails uses is AES, which is a symmetric Cypher. We won't go into details about how it works. As the HH said, we don't need to know these things. We just let someone else handle it. So AES is a symmetric Cypher could have or it could be a stream or block Cypher. Those are the two types of Cypher, a stream. Let me just, so a stream Cypher encrypt your bits individually. Whereas a block Cypher, it divides your data into blocks and then encrypt those blocks to encrypt the whole data. So AES is a block Cypher. So but before we talk further about AES, not the internal details, but before we talk about that, let's talk about what came before AES, which is DES or data encryption standard. So this was released in 1977 by NISD, National Institute of Standards and Technology, which is named differently back then. So this is the agency that I think provides guidelines on passwords and even for cryptography. So it was developed by IBM with the help of NSA, so the intelligence agency. So there was a concern back then that the NSA could pass a backdoor on the AES because they helped building the Cypher. So IBM described or NISD described how the algorithm works, how DES works, but some parts of it weren't really described fully or weren't really explained in specifically, specifically DES and other block Cypher's use substitution boxes, right? So these are, DES uses eight of these S-boxes, right? You could see numbers there and they're hard-coded. These are the specific numbers that DES used and they didn't explain why they chose these numbers, right? So what would people think, right? Like these are the numbers that NSA used to, for a backdoor to DES, right? They could decrypt the data without your key, right? So in 1990, so remember this was released in the 70s, in 1990 two researchers released a paper on an attack called differential cryptanalysis attack. These attacks, the block Cypher's including DES. So at this point there are other block Cypher's aside from DES, right? So, but they made a note that these cryptanalysis attacks weren't really that effective with DES, right? So that's an interesting note. So one of the creators of DES said, well finally you know about cryptanalysis attacks. So apparently in the 1970s, IBM and or NSA already know about cryptanalysis attacks and that's why they chose these numbers specifically to protect against those attacks, right? But they couldn't say what those numbers are for because they wanted to keep it secret, right? The US government wants it to be an advantage, right? They could decrypt some data but you know, not tell the public that they know about this. But apparently this is the height of the Cold War in the 70s but apparently the Russians also know about these attacks, right? So yeah, in 1997, 98, DES is being attacked, right? So it held up in 1990 but 97, 98 is already being attacked. You get powerful hardware. Computers were being built specifically to attack DES and it's not the cryptanalysis attacks. So what was the problem? They used a small key space. They used 56 bits which was awfully a concern in the 70s. IBM wanted 128 but guess who wanted 56 bits, right? So the NSA wanted to use 56 bits. So NISC said, well, right? We want a new cipher that would replace DES. So but instead of doing it the way we did with DES which is, you know, it was developed by IBM not in the open, you know, we want to ask for submissions, right? So 15 submissions, right? There were 15 submissions and that was, and we had five finalists in 1999 and it's an open process. It's very different from the way that DES was developed, right? So and in 2000, the Rindell cipher, if you've heard of it, it's a Belgian cipher. It was chosen as the AES cipher. So it was renamed to AES. So that's how we came with AES. So from DES which isn't recommended anymore but by NISD, we now have AES advanced encryption standard. So the standard here is because, you know, the US government NISD, right? The agency, you know, said that this is a standard that people would use but actually AES is used pretty much, it's pretty much actually the standard, right? A lot of applications use it, right? So it's, you know, it's, and the testament to that is NSA actually allows their data to be encrypted by using AES. So before that, they used their own ciphers, right? Their proprietary ciphers. But with AES, they said, well, it's good, you know, if it's good enough for NSA, you know, it's good enough for our AES applications. So 128 is the bit key size, right? 128 bits, just a note about, you know, the key sizes, right? You'd hear that the bigger keys, right, is better. Like if you're using SSH keys and you create, you know, and you use RSA, you would, you know, I think right now the recommendation is to use 2048 bits, right? But here we only use 128 bits because the key space only matters if that is the, it's the brute force attacks. It's the most, you know, it's the attacks that people use. If it's the brute force attacks, and it's, so RSA is different from AES. That's why the keys could be smaller. So in fact, with AES, you could only choose 128, 192, and 256 bits, right? So those are the only three options. And 128 is, you know, it's good enough. It would take decades for, you know, for AES to be broken, right? So then GCM, Galois counter mode, it's the mode of operation. Since we're encrypting by blocks, then that's, you know, there's a way to, like to encrypt those. So GCM is the recommendation, and that's what we're using. So AES 120 GCM, this is on the actual Rails code base, right? This is what we're using. But if you're using something else, or if you want to use something else, then you could do that as well. You could just change the cipher and your code would still work, right? So should I use credentials, right? Should you use credentials? If you have, if you haven't been encrypting your data, then yes, you should use credentials, right? But if you have something else, like if you're already doing something, if you already have policies in place to encrypt per environment, and then, you know, you don't want to mix them, like to mix your staging and your production keys, because, you know, then all your developers would need access to that key. Or in development, right? If they need that key, then, you know, you're exposing your credentials to probably unnecessarily to a lot of people. So, you know, check what you're using now and see if this is better or not, right? So, but definitely if you're not encrypting your credentials yet, it's good to use this new features. So what are the alternatives, right? EJSON is from Shopify. It uses JSON though. They have supposedly a replacement for that, which is ECFG, you know, I researched that, you know, included it on my slides. And then, you know, two days ago, I checked the repo and then it says abandoned, right? So it's like, so, you know, you could check EJSON. It's, I'm not sure how tight it is with Rails, but it has some good features. Like it's not using one key. Like every developer can have his own public key. So they are using a symmetric encryption, right? You have a public and private key. So, you know, check that out. Secrets, I believe, is the inspiration for the credentials feature. So it's not more as an alternative as, you know, what prior gems were out there. And then finally, I added this pull request. This is the pull request that merged where credentials feature was merged. And until now, it's still open. Because people have been saying, we need to use credentials on development, on staging, on test, right? And you only told us that we could use the credentials feature in production, right? So people have been replying, right? And it's very active. Like last I checked, maybe the past few days, you know, there has been a reply. So there is no answer right now from Rails core on how to handle, you know, per environment credentials. The code is there. You could use, you know, when I specified a different key and a different file. It's there, but then each and every one of the applications that use staging credentials would have to use those, you know, those code. And, you know, it doesn't, so it's not yet over, right? Like if, I think there would be more features that will be added soon. Some people have released gems to tackle this. And I think DHH also, you know, likes, you know, if you want your idea to be used, then put it on a gem and let's see how people would use it. So that's the current state right now. I actually bumped into one of the Rails core team member and he said he's gonna push something today before my talk, but I don't think he did. So as of now, yeah, you could use credentials, but yeah, I mean, you check on the status as well of what's coming in the next few versions. And that's it. Thank you very much for listening. And yeah, I think we have time for questions.