Securing Code Secrets - What is the relevance if the host gets compromised?

Question

I've been researching and testing different approaches when it comes to securing code secrets, and am unsure what the best options are, and if they even have any relevance once a host gets compromised.

Some standard approaches I've read about storing variables are:

• Compiled code
• Environment variables on machine or through Docker
• Files
• Encrypted/decrypted through keys to a vault API/DB

If a host gets compromised (admin access), secrets can be exposed via:

• Decompiling code
• Viewing env variables / files
• Memory dumps
• Viewing SSL traffic using private keys on host
• Decompiling and modifying code to expose possible encryption/decryption keys and output secrets once fetched from a vault

Are there methods that will protect secrets once a host is compromised, or is it just making the ability to fetch secrets more complex, so an intruder will find it more difficult to reach them?
If a host is secured and firewalled and admin access is tightly controlled, is there really any benefit to the added complexity of storing secrets elsewhere rather than on the host itself?

Answer 1

You mention the "host" being compromised, but the answer depends on just how the host is compromised. If an attacker has gained access to a user account with restricted privileges, then the jig isn't up yet! It will be, however, as soon as they find a privilege escalation vulnerability. That's because:

In general, if your application has access to the secrets, and someone gains root/administrative access to your machine, then there is no way to stop them from gaining access to your secrets.

This is basically just the first law of the 10 immutable laws of security. Now, additional steps may slow down an attacker. For instance, it may take them time to figure out how to extract, reverse compile, and find your decryption key. Or it may take them some time to make sense of a full memory dump though, or to figure out how to intercept traffic between the application and the hardware-decryption module. Unfortunately, it is effectively impossible to secure an application against a rogue root account (see Law #6 in the link above). As a result, if someone manages to take over root on host where your application is hosted, you should assume that all data the application has access to is compromised.