attr_encrypted and keeping your application safe

So you’ve installed the attr_encrypted gem as there’s some data that you need to keep safe, but also need to retrieve again.

This encrypts the data in the database, but if your application is hacked it doesn’t provide any help does it? What stops me from running{|p| p. api_password} to get all their passwords?

This is the difference between the two types of encryption mentioned in the article – one way encryption is inherently safer simply because there’s no simple way to reverse it.

Having said that, the two-way encryption is useful, simply because a lot of hacks get access to your database and nothing else. So two-way encryption will at least befuddle your attackers for a good time.

But what if the attackers manage to grab your source code as well?

If you remember, we defined our encrypted attributes as follows:

That means that to decrypt them, we need access to those keys.

If they are defined in our source code then anyone with the source code can decrypt that data.

But if they are defined elsewhere then the hacker will need more than just the source code and database to access them. The best place to do that is in an environment variable.

Our Person class becomes:

and we need to preload those environment variables onto our server somehow; something that varies from hosting platform to hosting platform – Heroku makes it easy, there are also gems such as figaro and dot-env to help with this.

The idea here is that we are adding small hurdles that our attackers must overcome; each individual hurdle isn’t really that big a deal, but add them all together and it’s not really worth their while to try and crack us. The database isn’t enough, you need the source code, the source code isn’t enough, you need the environment.

One last thing – what if someone manages to get in and run a Rails console on your app in it’s live environment? That way they have access to your environment as well.

Well, that’s beyond the scope of your Rails app itself; but comes down to good security practice in general.

When SSH’ing into your box, always use public-private-keys and disallow password login. That way, they can’t brute-force and guess their way in.

Consider limiting which boxes are allowed to SSH into your servers (for example, at most places I’ve worked, we only allow SSH logins from boxes that are connected to our VPN).

Again, these add small hurdles in the way of attackers; another step that they need to take before they get access to your database.

All of which makes you that bit less tempting as a target.

Do you know what to do but not how it works?

Ever wanted to understand why Rails views work the way that they do? Why variables from your controllers are visible inside your views?

Sign up below to get a free 5 part email course on how Ruby on Rails view rendering works and gain a deep understanding of the Rails magic.

We will send you the course, plus the occasional update from this web-site. But no spam, we promise, and it's easy to unsubscribe