Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102090
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ctors.net designates 209.85.213.47 as permitted sender)
MIME-Version: 1.0
Date: Thu, 3 May 2018 20:29:39 +0200
Message-ID: <CAN+C6bU3BJRmKpxLjaXMaJOKbKq1-+uG-=+xHQn=dSumsk_JPg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000efd097056b51624f"
Subject: [PHP-DEV] More secure credentials storage
From: tom@ctors.net (Tom Van Looy)

--000000000000efd097056b51624f
Content-Type: text/plain; charset="UTF-8"

Hi

I ended up in a discussion about using secure password storage today and
started thinking about solutions for the problem. Some frameworks suggest
putting all kinds of credentials in environment variables. This practice
seems to originate from a recommendation on 12factor.net.

The problem I see with this practice is that it is so easy to leak
environment variables. Like if you are running a phpinfo() page somewhere
that is not a very big deal until it contains all your passwords and API
keys in plain text. Jikes!

I favor putting credentials in config files that are outside of the
document root. That is also not perfect but at least the risk to leak them
from the environment is mitigated.

Now, I understand that the practice of using environment variables comes in
very handy if you use containers. Just launch your app in a container and
pass it some information about the environment, credentials, ... and you
can reuse the same container in the entire DTAP cycle.

So, how can we improve this situation?

As a PHP FPM user, my solution would be to add a sec_env[] configuration
instruction to the pool configuration that reads the configured value from
the environment, puts it in a more secure location and immediately unsets
it in the environment. Applications will need to read the credentials from
somewhere else, we can provide userland functions for that.

The credentials can be somewhere in the memory of the child process, or
maybe even better is to fork a separate process just to keep the sensitive
variables. The children would be able to communicate with this process over
domain sockets ...

The main intention is to get the credentials out of the environment
variables. You need to setup a connection to a database or API? Get a
password from the secure storage, make the connection and get rid of the
password.

Some side notes:

If it's an environment variable like FRAMEWORK_ENV=prod, which I think is
the valid use-case for environment variables, we don't bother with it.

For CLI applications on the other hand this issue seems less relevant, so I
did not try to solve that problem.

I am aware of tools like Vault, etcd, ... but they solve a different
problem and have their own caveats IMO.

I will be the one writing the proof of concept if this idea would make it
to an RFC. There are still some things I need to figure out but it seems
doable.

I'm looking forward to your feedback.

Kind regards,

Tom Van Looy

ps: today is international password day. What day is better to start a
discussion about secure password storage :-)

--000000000000efd097056b51624f--