I see why it is obviously bad to store a secret key and client ID in the source code for a web application. However, how do you go about the alternative? Surely, that information has to be stored somewhere. Is it stored in a local text file on, say, an EC2 instance which is running the server that gets read by the application?
6
-
@defalt Where should the secrets be stored?– BigMistakeSep 29 at 18:40
-
Secrets in source code are bad, but environment variables are potentially worse, because (a) they often get automatically dumped in error logs and (b) relying on app-specific environment variables makes it a lot more difficult to sanitize the environment of possibly-dangerous values (which is usually done when dropping permissions to spawn/exec)– Ben VoigtSep 29 at 20:44
-
@BenVoigt Got it. So where should the secrets be kept?– BigMistakeSep 29 at 23:08
-
2@BenVoigt Secrets in environment variables are most definitely not worse than secrets in source code.– Joseph Sible-Reinstate MonicaSep 30 at 0:55
-
OP, Are the client id and secret key used by your web server to access resources on some other server? If so, then the best solution for this is to use a hardware security module (HSM) or a cloud-based key management service (KMS). Related: security.stackexchange.com/questions/12332/…– mti2935Sep 30 at 13:47
|
Show 1 more comment
1 Answer
I've been going through this recently so I'll give my most recent answer.
If one is already bought into the AWS system, Secrets Manager exists. Other cloud providers likely have a similar mechanism.
In effect your secret is stored encrypted in AWS cloud. Your app must make an encrypted API call (bindings for multiple languages exist). At that point secrets are only stored in memory during runtime and otherwise encrypted at rest.
This type of thing can obviously be homegrown but at 40 cents a secret per month the use case would likely be pretty special to pay back the NRE at that rate.
