4 ms·

low hanging fruit like "encrypt everything" ...what? A database stops working as a database if you encrypt every field If you encrypt at rest/in transit (whic

by slifin 8y ago

low hanging fruit like "encrypt everything" ...what? A database stops working as a database if you encrypt every field If you encrypt at rest/in transit (which you should legally) then you're only protected against a very limited set of threats Encryption is not going to save you if you have SQL injection or webserver breech Encryption is good but protects against hardly anything, usually physical attacks, do not try and encrypt at the application level, password fields are encrypted because you should never need to query it Passwords are the exception not the rule

40acres 8y ago
I'm not a security export, so "encrypt everything" is simply a hand-wavy way to say "handle low hanging security holes". When you look at the cause of some of the large breaches in the past, many times they are very simple attack vectors and weak protections: phishing, passwords stored in plaintext, etc. As engineers, we are awed when flaws like Rowhammer and Spectre are exposed, but the fact is that a lot more data is being exposed by very simple means. The fact that corporations are still being breached by these efforts is troubling. I think it shines a bad light on both corporate entities and security consultants.
LinuxBender 8y ago
At my workplace, all attributes in the database are encrypted. In fact, we are contractually obligated to do so. This does not limit the use of the database. Rather, it changes how we use the database. i.e. We decrypt, store working sets in memory, re-encrypt prior to storing in the database.
- idontpost 8y ago
  That's impractical for the vast majority of use cases. The performance costs would be enormous, turning millisecond response times into seconds in many cases.
  - LinuxBender 8y ago
    For existing database design for many, sure. This requires rethinking how you access your data and changing the architecture and data flows accordingly. I am not in any way suggesting it would be trivial for existing applications to suddenly do this. It requires forethought.
  - v_lisivka 8y ago
    They store unencrypted data in memory instead of hard drive. From security perspective: nothing changed, so their access times may be even faster than with traditional approach.
    - LinuxBender 8y ago
      Actually it means that you must be able to access memory when the server is running. Still possible, but much more difficult and requires gaining root on the server while it is running and has decrypted the data, or finding some RCE that allows direct access to this memory. We have numerous pen testers and code reviewers that look for and test for such things all the time. This also means evading various monitoring tools that security and network operations centers are watching. Again, still possible, but much more difficult. This also means, disks walking away are always encrypted. We physically shred all of our disks, but humans can make mistakes.
    - idontpost 8y ago
      You're assuming that all your unencrypted data fits in memory. For most of us, that's not the case.
PurpleBoxDragon 8y ago
>password fields are encrypted If you are encrypting your passwords you are already doing it wrong.
grumio 8y ago
I hope by "password fields are encrypted" you mean that only hashes are stored.

by slifin 8y ago

40acres 8y ago

I'm not a security export, so "encrypt everything" is simply a hand-wavy way to say "handle low hanging security holes". When you look at the cause of some of the large breaches in the past, many times they are very simple attack vectors and weak protections: phishing, passwords stored in plaintext, etc. As engineers, we are awed when flaws like Rowhammer and Spectre are exposed, but the fact is that a lot more data is being exposed by very simple means. The fact that corporations are still being breached by these efforts is troubling. I think it shines a bad light on both corporate entities and security consultants.

LinuxBender 8y ago

At my workplace, all attributes in the database are encrypted. In fact, we are contractually obligated to do so. This does not limit the use of the database. Rather, it changes how we use the database. i.e. We decrypt, store working sets in memory, re-encrypt prior to storing in the database.

idontpost 8y ago
That's impractical for the vast majority of use cases. The performance costs would be enormous, turning millisecond response times into seconds in many cases.
- LinuxBender 8y ago
  For existing database design for many, sure. This requires rethinking how you access your data and changing the architecture and data flows accordingly. I am not in any way suggesting it would be trivial for existing applications to suddenly do this. It requires forethought.
- v_lisivka 8y ago
  They store unencrypted data in memory instead of hard drive. From security perspective: nothing changed, so their access times may be even faster than with traditional approach.
  - LinuxBender 8y ago
    Actually it means that you must be able to access memory when the server is running. Still possible, but much more difficult and requires gaining root on the server while it is running and has decrypted the data, or finding some RCE that allows direct access to this memory. We have numerous pen testers and code reviewers that look for and test for such things all the time. This also means evading various monitoring tools that security and network operations centers are watching. Again, still possible, but much more difficult. This also means, disks walking away are always encrypted. We physically shred all of our disks, but humans can make mistakes.
  - idontpost 8y ago
    You're assuming that all your unencrypted data fits in memory. For most of us, that's not the case.

PurpleBoxDragon 8y ago

>password fields are encrypted If you are encrypting your passwords you are already doing it wrong.

grumio 8y ago

I hope by "password fields are encrypted" you mean that only hashes are stored.