10 ms·

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

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?

aeronautic 9y ago
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.
- stephenr 9y ago
  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?
  - k__ 9y ago
    Can't you encrypt the entered email and search with that?
    - aeronautic 9y ago
      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.
      - arjie 9y ago
        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?
        aeronautic 9y ago
        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.
        stephenr 9y ago
        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.
        aeronautic 9y ago
        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.
- ams6110 9y ago
  Never mind that email addresses are sent in the clear all over the internet every day in normal SMTP traffic?
- creepydata 9y ago
  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-not/ https://www.troyhunt.com/im-sorry-but-your-email-address-is-...
- wglb 9y ago
  I am wondering if you are clear on exactly what database encryption protects you against. Hint: not much at all.
mirimir 9y ago
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-February/042930.html https://lists.torproject.org/pipermail/tor-talk/2017-Februar...
brlewis 9y ago
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?
- nkozyra 9y ago
  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.
  - spydum 9y ago
    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.
- pjungwir 9y ago
  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.
- e12e 9y ago
  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.
FooBarWidget 9y ago
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.
- pjungwir 9y ago
  Good example! So many vulnerabilities come from a lack of imagination. :-)
- yetanotherjosh 9y ago
  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.
  - FooBarWidget 9y ago
    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.

aeronautic 9y ago

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.

stephenr 9y ago
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?
- k__ 9y ago
  Can't you encrypt the entered email and search with that?
  - aeronautic 9y ago
    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.
    - arjie 9y ago
      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?
      - aeronautic 9y ago
        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.
        stephenr 9y ago
        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.
        aeronautic 9y ago
        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.
ams6110 9y ago
Never mind that email addresses are sent in the clear all over the internet every day in normal SMTP traffic?
creepydata 9y ago
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-not/ https://www.troyhunt.com/im-sorry-but-your-email-address-is-...
wglb 9y ago
I am wondering if you are clear on exactly what database encryption protects you against. Hint: not much at all.

mirimir 9y ago

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-February/042930.html https://lists.torproject.org/pipermail/tor-talk/2017-Februar...

brlewis 9y ago

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?

nkozyra 9y ago
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.
- spydum 9y ago
  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.
pjungwir 9y ago
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.
e12e 9y ago
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.

FooBarWidget 9y ago

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.

pjungwir 9y ago
Good example! So many vulnerabilities come from a lack of imagination. :-)
yetanotherjosh 9y ago
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.
- FooBarWidget 9y ago
  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.