Hacker News Reader

Comment by pjungwir | Hacker News Reader

Totally agree about the encryption. I've set up databases to run on encrypted disks (LUKS or nowadays on AWS you can get encrypted EBS), but I feel like that is really just to tick the "encrypted at rest" compliance checkbox, because if the machine is turned on, anyone can read the data (subject to normal file permissions of course). As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it.

Also this business of two layers of encryption: yep, anything encrypted can't be indexed or searched (basically). At best you can encrypt the query input too and compare for strict equality---sort of like hashing passwords. (Is that what he means?) I've never seen anyone hash email addresses though. And encrypting billing details . . . okay, I guess, although if the app has the decryption key, then what security are you really adding?

View on HN

We use disk encryption to protect against a specific attack that had occurred in the past: the attacker hacks the hosting provider's admin panel and uses it to reboot our server into a rescue system, in which he has access the raw disk.

Good example! So many vulnerabilities come from a lack of imagination. :-)

Interesting, what hosting provider/system are you talking about here?

It seems to me having admin panel access is an even higher level privilege than having root on the box itself, for any VPS host environment I've personally used before. Linode for instance lets you open up a root shell to your running box, which doesn't even use SSH. I'm surprised it isn't total game-over if your admin panel access is compromised.

The provider that got hacked was Linode. That was a real bummer: we secured the server to the teeth and then we got hacked through a channel that we had no control over. :(

But there are many providers out there where through the admin panel you can gain access to a system. Many providers provide access to the server's terminal. Even if you can't login, you can reboot the server, and at the boot loader stage you can boot the OS in rescue mode, during which you can mount the hard disk.

If the hacker gets access to the database due to a network config error, then they will be able to query the database, but only get records with some sensitive fields encrypted.

Given the number of email addresses that have been hacked and stolen (3.75 billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra bit of encryption on email addresses is worthwhile. We push that into our ORM layer and can easily flag any field in the database to be encrypted.

On very, very high volume accessed tables, you may not want to do that. But for user logon details -- for us it was a no brainer.

Wait, so you encrypt the user's email before it's inserted into the table?

Are you using a different field for 'username' on logins, or do you have to jump through some hoops to find an encrypted email to do a login check against the pw hash?

Can't you encrypt the entered email and search with that?

Password hashes are handled separately using bcrypt - another story.

For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search with the encrypted value that is stored in the db. App code provides plain-text email, ORM encrypts and searches with that value. Symmetric encryption of short strings is pretty fast and this is not a high volume API.

We use rate limiting on the API to protect against DOS on this API.

If it's symmetric, then doesn't an app vulnerability make it possible for you to leak your key? Then the app also contains access credentials to the DB, so vulnerabilities in the app will still lead to real access to the DB, right?

Yes, we're not protecting against the app being attacked, the key being jacked and then the attacker getting access to the db. Rather, we're protecting the database against being accessed directly. That could happen due to an error in configuring network access to the database or another service could be compromised that has access to the same database -- as has happened to many mongo databases over this year.

So your solution to fixing a basic ops problem 'software package A was exposed to the internet with(out|effectively no) auth' is: encrypt shit in an ORM layer and destroy your ability to do anything beyond absolute string comparison queries.

No thanks.

No, we don't encrypt indiscriminately. We selectively pick fields to encrypt - fields that are highly sensitive.

And you are right, we do this because an ops error can easily make a mistake sometime in the future and probably will one day. We all make mistakes and defense in depth is all about that.

This is an interesting solution, thanks for sharing. This would be a cool feature to build into open source ORMs.

This is a good idea, but only for fields which can never be used in range based index lookups.

It does seem like emails are a good fit for encryption. I can't see wanting to do anything more than simple equality checks.

I could see a use case to see which emails are from what TLD.

For instance, all @gmail, all @yahoo, all @aol.

Maybe you want to do the cool "hey we noticed your email on haveibeenpwnd, you should change you password here just in case". In which case, anything other than plain text could prevent that from happening.

Hashing an email in that sense gets much more difficult, no?

If you have enough emails that you can't SELECT * FROM users and do that query in memory, you're probably in a spot where you should not be picking security advice from a blog like this.

(That's not a negative as to this blog, it's really good and I've recommended it to multiple clients already, but that level of acumen should already be assumed at that scale. If you don't have it, this blog post is insufficient.)

I see. Makes sense. Thanks for sharing this approach.

Never mind that email addresses are sent in the clear all over the internet every day in normal SMTP traffic?

Psst, I really hate to break it to you but you are "stealing" and "hacking" your users email addresses ever time you send them an email!

https://www.troyhunt.com/im-sorry-but-your-email-address-is-...

I am wondering if you are clear on exactly what database encryption protects you against.

Hint: not much at all.

Maybe it's useful to mention security procedures for VPN privacy services. You accept credit/debit card payments, and need to retain records for dealing with fraud, satisfy VAT requirements, etc. Your exit servers need to check account status, check for existing connections to limit concurrency, and so on. But in case adversaries have your exit servers seized, you want them to be clean. So you run them read-only, with no persistent storage, and you do authentication etc with remote servers, using hashed account names and passwords.

Countermail, for example, does the same for its email servers. For Tor relays, there's tor-ramdisk.[0]

0) https://lists.torproject.org/pipermail/tor-talk/2017-Februar...

As far as I can tell the only threat this is protecting against is someone physically pulling the drive and walking off with it.

Are you saying that that threat isn't worth protecting against?

Every potential threat should be considered, but weighed against likelihood when prioritizing.

Sometimes you make cost/benefit consolations. 100% airtight would be great, but 100% airtight doesn't actually exist. Most organizations with finite resources have to make risk/reward decisions when there are as many threats as there are with web development.

The cost for encryption at rest is single digit percentages these days.

I push for encryption at rest on ANY cloud provider storage for one main reason: I have no control over their disk disposal or reuse mechanisms. They can claim they wipe the data, but I have no way to test that reliably.

As for disk encryption plus FS encryption, keep in mind in AWS or Azure, it's possible for a misconfigured IAM or SPN to leak access to the disk blob.. If it was encrypted with a key separately, the risk is mitigated. Again, it's just too easy to implement on almost every cloud provider thes days.

No, and I've set it up many times. It's just . . . whenever I talk to people about this I get the impression they think it secures them against more. Non-technical people especially (but not just them) worry about someone "hacking into the system". Full-disk encryption is almost more like physical security than digital security.

It also makes it easier to move servers, recycle hard drives etc - safe in the knowledge that the whole disk was encrypted - without worrying about where the used disk ends up.

The only real alternative is to manage your own servers in house and degauss/drill through old drives. And this might be more of a hassle (at scale) with ssds.

Consider a faulty disk that is replaced. It might be possible to recover data by using advanced techniques - but might not be possible to remotely wipe it. Now you have to hope your provider manages to safely dispose of the drive.

Reply on news.ycombinator.com