How do you manage secrets in conf_global.php?

[Runar]

There are many ways to handle/store secrets (such as database username and password) when developing websites. Some use environment variables, while others write the secrets directly in the code. Currently I use fastcgi_param in an nginx configuration file to make them available to PHP, but the downside of this is that the variables and their content is displayed together with all other environment variables, for example when using phpinfo().

So, how do you solve this? Do most people just store them in conf_global.php?

[Ryan Ashbrook]

Yes, that's the most common method.

[CoffeeCake]

What a great question, @Runar.

[Matt]

conf_global.php or new constants in constants.php are the quickest ways.

[CoffeeCake]

Quickest and common aren't always most secure or best case for every implemention, and I think it's great to spawn a discussion on this!

As we maintain code repositories for our IPS instance, an important consideration is that we don't include those secrets in committed code and maintain separate values for each instance. Our production values are intentionally different from test. This adds an additional layer of assurance that we won't inadvertently hit the wrong database, even though we isolate the environments on separate networks as well. Security is all about layering and compensating controls.

Your secrets are only as good as your weakest link. If somebody else can access your filesystem in a shared hosting environment, or can write code to output the values of variables set within the IPS session, then your efforts are likely giving you a false sense of security.

You can do things like encrypt credentials with a library and decrypt them in constants.php, or use a proxy for MySQL where the credentials are stored at the proxy level. Referring to values in a file that lives out of your web root is another option, and as you pointed out, passing them through the web server. Lots of options. Just remember to consider that with the most secure of deadbolts, if you leave it unlocked, or the back door open or a ladder propped up against the side of the house, you're only as secure as your weakest link.

[Runar]

1 hour ago, Paul E. said:

Quickest and common aren't always most secure or best case for every implemention, and I think it's great to spawn a discussion on this!

Thank you for your inputs, @Paul E.! I'm glad to see I'm not alone with thoughts and ideas on this topic.

Can I ask how you avoid committing secrets to your repositories? I did some experimenting with Docker recently, and Docker Secrets worked perfectly. But I have now decided to use Ansible and ordinary servers instead of containers, and so far I haven't found anything as easy and secure as Docker Secrets.