On 7/24/18 03:25, Marco van Eck wrote:
> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy, and forcing me to enter the
> password over and over again.
I'm late to the party here, but I just noticed this thread and I'm
excited about it. Security is not about perfection; it's about managing
risk, about layers of mitigations, about iterative improvements, about
the difficulty of attack against the value of assets protected. That
plain text pgpass file does irk auditors, and it's always driven me
crazy too.
On 8/1/18 08:33, Marco van Eck wrote:
> With the result libpq only allows the PGPASSCOMMAND
> environment variable, which can only be defined by the executing user,
> and will be executed by the same user. It only reduces the need of
> unencrypted password's in a file.
>
> I think this solution is secure enough, shall we solve this
> feature-request?
I'm happy with this. I think another useful question is what parameters
are needed for someone to write a callout-program that itself integrates
with something like HashiCorp Vault or the KMS solutions from all of the
major cloud providers or various token-based authentication protocols.
But we can always make the case later for adding some particular parameters.
Sockets sound nice (Craig), as does deeper database integration (so for
example postgres_fdw or pg10 native replication getting credentials
based on connection parameters, object owners, etc). But this idea
already helps with things like making plain-text password files less
common in system backups.
I'm hopeful that this moves forward. :)
--
Jeremy Schneider
Database Engineer
Amazon Web Services
