it’s 2026. build like you’re already going to get hacked, because sooner or later you probably will
collect less. only keep the customer data you actually need. anything you never store can’t leak
encrypt everything you keep. not just passwords and card numbers: names, emails,…
Commit
26c37b3
the encrypt everything needs some better clarification here. Doing it at the application layer adds massive architecture and performance overhead. Industry best practice is at the storage or engine level. Keep the application layer to PII, secrets and anything else truly…
I've been thinking about this as well.
Would an attacker actually try that? In a mass attack they probably don't bother and just try to dump the db and move on. On a targeted attack they might ..
I've been thinking about entering the encryption keys in memory after server reboot - not stored anywhere.
Still, if your app can read the data, like email address, through whatever mechanism, anybody with access tot he code can add some lines to dump the data to plain text, no?
commit 26c37b3
You can’t just store the encryption key only in memory, you would loose the ability to decrypt your data on every reboot. The encryption key gets stored on a separate physical device normally a KMS and fetched into memory only for that session. At GPTree we use a unique DEK for…
I’m sorry I miss read your post at first as storing the key in memory as the primary place rather than what you actually said pulling the key into memory after the reboot