2

I am testing an in-development app locally.

Currently I use environment variables to store JWT secrets and database usernames and passwords.

I am interested in further securing this, and found out about secret managers (like Conjur).

How is this anymore secure than what I currently have?

Isn't it just a transition from storing my database credentials directly, to storing my Conjur credentials in exactly the same way I currently store my database credentials, and then requesting my database credentials? I must be misunderstanding something.

How do secrets managers actually further secure credentials, and what are the most secure best practices for storing JWT secrets and database passwords?

theonlygusti
  • 207
  • 1
  • 2
  • 6
  • 1
    Related: https://security.stackexchange.com/questions/12332/where-to-store-a-server-side-encryption-key – mti2935 Jun 28 '21 at 16:54

2 Answers2

-1

Store secrets on environmental variables is a bad idea, if you don't have more options of course you can go for it, but having your secrets on a specific service for store this type of information gives you more benefits in terms of security and management.

For example your JWT stored encrypted on your service will directly go safely from the disk of the service (that is properly encrypted), directly to your service with TLS or mTLS to the memory of your backed. Also if you server is compromise your secrets wont be compromised. I'm sure there are more benefits but those are the ones that came to my mind easly

camp0
  • 2,172
  • 1
  • 10
  • 10
  • What about the credentials for the secrets service though? – theonlygusti Jan 29 '21 at 14:51
  • In general, not always works for all the services, you can generate a client cert and use mTLS for verify your backed with your secrets server. – camp0 Jan 29 '21 at 14:52
  • why is a client-side cert more secure than client-side environment variables or config files? – theonlygusti Jan 29 '21 at 14:54
  • Is not that is more secure, depends on how you manage your server, if nobody can access to your server then all is fine, if multiple users use your server and they have root permissions any of them can see that variables or with admin. So the question of what is more secure than other depends of multiple variables, you just mention env variables versus secret service. – camp0 Jan 29 '21 at 15:42
-2

If you are performing simple SECRET management locally, you can store your secrets in a gpg encrypted file that is base64 encoded containing exported bash variables. That file can be locally decrypted to stdout and sourced into your running bash environment as bash variables. Pipelining this activity correctly is key to never writing it to disk (including your shell history). (edit) environment variable accessibility in Linux

shadowbq
  • 117
  • 6
  • 1
    Environment variables cannot be read by other users, but at least under Linux and most other Unix variants, without non-default hardening, they are visible to other processes running as the same user. And they are of course always visible to administrators. – Gilles 'SO- stop being evil' Oct 25 '21 at 18:55
  • @Gilles'SO-stopbeingevil' what about `VAR1=value1 VAR2=value2 myProgram args`? isn't this specific to this application? – kelalaka Oct 25 '21 at 20:09
  • 2
    @kelalaka What about it? It only sets the variables in the environment of `myProgram` and its child processes. But they are visible from other processes running as the same user via `/proc` or equivalent. E.g. `ps eww` on Linux. That's not a killer argument against environment variables: those other processes can read and modify the same files as `myProgram` anyway, so there's no expectation of security. But the statement “ENV variables are not readable outside of the running bash session, nor by other administrators on the machine” is wrong, and this is very relevant here. – Gilles 'SO- stop being evil' Oct 25 '21 at 20:11
  • @Gilles'SO-stopbeingevil' I see, it is not restricted to the process. Thanks. – kelalaka Oct 25 '21 at 21:41