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?

1

2 Answers 2

-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

4
  • What about the credentials for the secrets service though?
    – minseong
    Jan 29, 2021 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, 2021 at 14:52
  • why is a client-side cert more secure than client-side environment variables or config files?
    – minseong
    Jan 29, 2021 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, 2021 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

4
  • 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. Oct 25, 2021 at 18:55
  • @Gilles'SO-stopbeingevil' what about VAR1=value1 VAR2=value2 myProgram args? isn't this specific to this application?
    – kelalaka
    Oct 25, 2021 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. Oct 25, 2021 at 20:11
  • @Gilles'SO-stopbeingevil' I see, it is not restricted to the process. Thanks.
    – kelalaka
    Oct 25, 2021 at 21:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .