A trick i've started doing is encrypting my env vars, then hard-code the decryption key in the code
that way if the provider gets popped, they need my binary to decrypt it
it shouldn't be necessary and it sounds stupid, but in cases like this, it proves invaluable (it appears they don't have customer code/binary access, but maybe that wasn't important enough to mention)
I think this is a great example of temporarily effective "security through obscurity." It's also a trick that will only continue to work so long as it doesn't get adopted too widely.
It buys you time. I had my Anthropic key on Northflank set as an env var as-is and only found out about the incident from the HN front page 6 hours later (I didn't even get an email).
I rushed to the Claude platform console and was expecting to see a 4 figure usage bill or something. Luckily there was no usage.
But imagine if I were traveling. Even a rot13 of the key would've bought me enough time to rotate.
2 lessons:
- don't name your env var "CLAUDE_API_KEY". Call it "ARG_1" or something
- at least do some obscurin' so that the value doesn't start with "sk-ant..."
At this point, I kinda feel like the obscurity is our best mechanism for mitigation :(
Obscurity has always been party of security and will never go out of style.
It's Obscurity Turtles all the way down.
Give it about a week until AI agents add his "tip" to their training...
Been doing something like this for a while with a single self contained .sh file that contains a python script:
https://github.com/thiswillbeyourgithub/envlocker
lock your env vars in hardware. even the whole server and code is compromised, the secrets are still safe.
so you dont need env2 to decrypt env1.
https://seal.zone/ does this
That's interesting but if the Azure hypervisor on the server hosting the VM is off limits then it's kind of false sense of security. They protect the key via a sidecar AMD SEV-SNP VM, and if you can't break into the hypervisor, sure, there might be an attack that doesn't involve doing that and only doing lateral movement, but an actual attacker isn't going to respect that boundary.
I will give you one better - encrypt the variables and move the secrets to a different server running hashicorp. Then load the secrets and keep them only in RAM.
Or env1 is the key to decrypt env2
if the provider gets popped doesn't the binary get popped too? then simply use an LLM to reverse engineer the binary and get the key?
If its a targeted attack, they'll know and probably "crack" it. If its just data trawling, you might get owned one day if they bother, but likely the env `AWS_KEY=encrypted_abc` looks reasonably close to `AWS_KEY=unencrypted_abc` and any API key probing will just look like it got rotated already.
I think siblings are correct that the more widespread this is, the less effective once every dump is run through a "also look for keys in the binary" step.