Re: scram-sha-256 encrypted password in pgpass

Stephen Frost <sfrost(at)snowman(dot)net> writes:

> Greetings,
>
> * Tim Cross (theophilusx(at)gmail(dot)com) wrote:
>> I suspect it is unlikely you will ever see a .pgpass solution which
>> supports encryption. There are just too many 'chicken and egg' problems
>> - you need a key to encrypt the .pgpass file, but now you need to store
>> the key securely. Problem made more difficult because different
>> platforms all do this in different ways and with different levels of
>> sophistication. While it could be done, the amount of work required is
>> probably more than the desire for anyone to implement it (not a big
>> enough itch).
>
> I generally agree with most of what you had here, but to this point I
> disagree- it'd actually be quite useful for libpq to gain capabilities
> in this regard, as it's something that developers these days are clearly
> interesting in having provided by a library (up to and including vault
> solution integration, which is becoming more and more a standardized
> thing, in order to get the needed key), so I dislike the implication
> that we won't do that or that we'd look down on a patch which moved us
> towards such a solution. There's certainly some of us in this community
> who would very much look positively on such a patch.
>

I certainly didn't mean to imply anyone would 'look down on a patch'.
However, I am sceptical about such a feature being added to PG and
supported on all supported platforms. The amount of work is non-trivial,
complex and difficult to get right. I'm also not sure trying to provide
this functionality at the PG level is the correct way to go. Adding
functionality within PG to support external solutions would be
beneficial and more achievable, but implementing a full solution less
so.

The biggest challenge for security is complexity. In environments where
you find formal security policies, the environment is typically complex
with multiple systems, not just PG, requiring secure 'vaults' for
passwords and keys. The last thing you want is multiple separate
solutions. You want one solution which works across all your systems, is
easy to maintain and keep secure and easy to audit/monitor etc. Adding
multiple different solutions only adds to complexity. You don't want one
system for managing PG credentials, another system for managing web
credentials, another system for managing server credentials etc. You
want one solution. I know some will argue this is bad because it puts
all your eggs in one basket and this is a risk. However, the reality is,
most places simply don't have sufficient resources to manage multiple
baskets in a secure manner and often, once one basket is compromised,
the others will soon follow. There are two big challenges in security.
The first is preventing compromise and it tends to get a lot of
attention. The second and just as important, is monitoring and becoming
aware of compromise. This is often overlooked and when you examine the
history of data breaches, you notice that in all of the most sever
examples, a common thread is the organisation was unaware of the
compromise for some time. Having multiple baskets creates policy and
process complexity, increases the amount of monitoring and auditing
required and will generally reduce overall security.

Providing additional APIs and facilities in libpq and other areas of PG
to support external vaults would be useful. Adding secure vault
implementations to PG less so.

--
Tim Cross