Original subtitles

In this episode, we're having a look at ActiveRecord encryption, which is a very important part

of protecting your data.

And this differs from hashing that you might see with device or other authentication methods

where your password is hashed to the database, but it's no longer reversible to come out

with the original password.

Instead, when you log in, you would just compare that log in password to the hashed value

that stored in the database.

But with ActiveRecord encryption, instead, we are encrypting the data at rest, so in the database

level, and it can be decrypted within our view.

So in this example, we have our description, which is an action text, and we're going to encrypt

that data as well as a passphrase.

So when we create the user, it doesn't seem like anything special is happening until you look

at the application logs.

So if we scroll up a bit, we can see where this user has been created, and then we can see

that the passphrase, instead of having the original data as talkosoup, it is encrypted.

And the same for the action text that was inserted, the body is encrypted, so you can't really

make sense of its information.

The one important thing to note is that Rails does a good job at certain attributes that

will automatically filter its value from the logs.

So you can see with the passphrase, I did not do in this example application anything different

for the passphrase, but the description you'll see that it comes over as plain text,

and that would be a security concern if this attribute needed to be protected.

And there's a lot of reasons why you would want to use something like active record encryption,

and some of its highlighted benefits is if your database is ever leaked or the logs are

ever leaked, then the actor who gained access to that information wouldn't be given privy

information.

But of course, with the encryption, we have the decryption layer, which is done at the application

level, and as we use this application, we're able to then see it in plain text.

So the first thing that we'll do is call Rails action underscore text, colon install, to install

the migration for action text, and to get that all set up, we'll then generate a scaffold

for a user's table, and we'll have a name, we'll have an email address, and then we'll have

some kind of protected information that would be really important not to leak out.

So we'll call this the passphrase.

And so once we have this done, we can go ahead and run our migrations, and while we're in the

terminal, we'll go ahead and run the command db, colon encryption, colon init, and then we can

copy the output from this and add it into our credentials.

So we can run the bin Rails credentials, colon edit, and then we can simply just paste this in here.

And this also does work if you have multiple environments.

So if you pass the environment flag into the credentials edit, and you specify it in an

environment like the development, then you would be able to do the same thing.

If I wanted to run this command again to generate a new set of credentials, we could do that,

so we can download this into our productions and cryptic credentials.

And so we'll go ahead and set up the description, which is using the action text.

So in the user model, we do a has rich text.

We'll set this for the description, and if we want to start encrypting this, all we have to

do is set this, encrypt it, is equal to true.

And that's all you have to do to enable the encryption for action text.

We of course would need to come into the user's controller in the permitted parameters,

and we would also need to add the description.

But we're not having to do anything extra around the encryption.

Same way for the views, in the user's form, we can come in here, I'll just reuse this

bit of code, instead of email, we'll have the description, and then we can change this to a rich

text area.

And so now we have a fully functional encryption at rest, feature, for the action text.

And the nice thing about this is that we might be using action text in many areas of our

application, but perhaps only this description field is the one that really needs to be

encrypted because it contains personally identifiable information.

And so then if you've created a modern Rails application, you can come under the config

initializers, and there should be a filter parameter logging.

And within here, there's already some examples.

And if we needed to add an additional one by the description, we can do that here, and

so now whenever we save something to the database, or anything comes through our application

from the user input, this would be filtered out, so we wouldn't see the implying text

in the logs.

So now we just have to deal with the passphrase.

And for that, we can do an encrypts, we can specify our passphrase, and that's all you

have to do, and now this attribute will be encrypted at rest.

However, there are some additional options that we may need to be concerned about.

For example, if you want to be able to search on this attribute, you're not going to

be able to by default.

Because there is a flag called deterministic that is set to false by default.

And if you never need to query the passphrase, then it's going to be best practice to

have this set to false.

And that's going to be the most secure way to store the data.

But if there is a use case where you do need to query this, then you would want to set

the deterministic set to true.

And so this way, you're going to be able to do something like a user that find by, you

can specify the passphrase, and then you can put in whatever string that you need.

And because the passphrase attribute is set to deterministic, then you would be able to

do this kind of query.

However, if it was set to false, then you're not going to be able to query the passphrase,

and you would just get a nil return in this particular example.

Another thing that you may want to do, and this more dependent on your database, is to ignore

the case.

You can set this to true.

You can also set it to downcase.

So if you have something like an email address, then you can set the downcase at that

to true.

So actually convert the value to downcase when it's getting stored and encrypted.

And if you will use ignore case, then it will be important that you add another attribute

to your database, and that'll be the passphrase in this particular case.

But you need to pre-fixes with the original underscore and then the attribute name.

By adding in that attribute, then you're going to be able to use this ignore case, and

that will store a downcase version before it's encrypted of the passphrase, but then it

will store the passphrase in its original text.

And this mainly going to be important when you're doing a query, and this will highly

vary based on your use case.

And depending on your situation, you might have some validations that you need to perform,

and we can do that very easily as well with a validates, and then we specify our passphrase

in this case.

And we can do something like a uniqueness, and we can set this equal to true.

And let's say we do have some kind of serialization that we are doing.

Maybe a user has a group of settings, so you've added a JSON data type, and let's just

call it settings to your database, and you want to encrypt this, because it might contain

some sensitive information.

And so you add the encrypt settings, and then you also add the serialized settings.

And maybe we would set this to a hash or JSON or something similar.

And this will work, however, the one issue here is that we would need to perform the serialization

before the encryption, because the encryption is going to rely on the object being in

a string, and not a more complex object like a hash.

And so now we can test this out, we'll create a new user, we can enter in a description,

and then we can enter in something for the passphrase.

And if we go to the show page, we can see, and plain text, the L'Orealm Epsom of the

description, and we can see the passphrase.

And if we were to go to the logs and scroll up a bit, we can see where we have our posts

for the user.

And within the prints of this request, we have the user's name, as Jane Doe, we have the

email address, the description is now filtered, so we did not see the plain text version

of this, as well as the passphrase is filtered by default.

But if it wasn't, then you would be able to add that to the filter parameters, logging

within the Config Initializer.

And even in the SQL queries that are creating the user, and inserting in, the encrypted attributes

for the rich text, we can see that the passphrases encrypted, as well as the body

for the action text.

And if this is a feature that you need to add into your application, then I would highly

recommend reading through the ActiveRecord Encryption documentation.

And the ActiveRecord Encryption is much more extensible than we have covered.

There are different things around the key management that you're able to do.

If you have a different kind of strategy that you need to use for the encryption, and you're

even able to rotate keys, providing that you give a previous key, just so you can

so decrypt the content, and then you add in the Active key for any new content or updates.

And if you realize that you need to add encryption after the fact, after you already

have your database in production, and it's now determined that one of the attributes on

a table does need to be encrypted.

You are able to do this out of the box with ActiveRecord Encryption, and you would simply

set in your environment.

They can figure ActiveRecord Encryption and support Unencrypted Data.

So you would still be able to read the data that was non-encrypted, but I think it's

also important, and now it probably has some kind of rate task that would then take all

the data and then encrypt it.

Because you would want to leave one of the columns in your database that has some encrypted

data in some unencrypted data in there too long.

I think a rate task or something that can quickly get all of that data encrypted would

be your best bet.

And then you can come back and disable this flag.

And there's also great support for the previous encryption schemes.

And so let's say you had said it previously to determine a sick is set to false, or you

just didn't have this deterministic flag at all.

It defaults to false, but now you need to have a deterministic because later down the road

you've now decided that this needs to be a choreoble attribute.

And so there's a lot of good information here, and a lot of information that really is

specific use cases depending on what you're currently experiencing.

Well, that's all for this episode.

Thanks for watching.