Hacker News Reader

Comment by slifin | Hacker News Reader

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

View on HN

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.

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.

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.

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.

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.

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.

You're assuming that all your unencrypted data fits in memory. For most of us, that's not the case.

>password fields are encrypted

If you are encrypting your passwords you are already doing it wrong.

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

Reply on news.ycombinator.com