Hacker News new | past | comments | ask | show | jobs | submit
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.
loading story #50314036
loading story #50311457
loading story #50313248
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

loading story #50313041
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.
loading story #50311833
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?
loading story #50313659