Re: Have an encrypted pgpass file

On 24 July 2018 at 10:08, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 24 July 2018 at 05:53, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
>> On Wed, Jul 18, 2018 at 5:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
>>> > On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck <marco(dot)vaneck(at)gmail(dot)com>
>>> wrote:
>>> >> Since .pgpass files contain plain-text passwords, I searched for an
>>> >> alternative.
>>> >> In the attached patch I've added the possibility to run a command to
>>> produce
>>> >> the content of the pgpass file, in exactly the same format.
>>>
>>> > ... Here you side step those questions completely and make that the end
>>> > user's problem. I like it.
>>>
>>> ... but doesn't this just encourage people to build hacks that aren't
>>> really any more secure than the unreadable-file approach? In fact,
>>> I'm afraid this would be an attractive nuisance, in that people would
>>> build one-off hacks that get no security vetting and don't really work.
>>>
>>> I'd like to see a concrete example of a use-case that really does add
>>> security; preferably one short and useful enough to put into the docs
>>> so that people might copy-and-paste it rather than rolling their own.
>>> It seems possible that something of the sort could be built atop
>>> ssh-agent or gpg-agent, for instance.
>>>
>>
>> If the goal is not unattended operation but just unannoying operation, I
>> think the first example he provided is already that use-case. If you
>> already have gpg configured to use gpg-agent, then it just works. You get
>> encryption-at-rest, and you don't have to type in your password repeatedly
>> in the same continuous shell session.
>>
>
> ... and the attacker steals the key from gpg-agent.
>
> Grabbing it from a process's memory is a bit harder than grabbing contents
> of a file, but not much harder. If the agent is remote then that's harder,
> but you can just ask the script to decrypt the pgpass for you, so again,
> not much of a win.
>
> Even with a hardware crypto offload device the advantage here seems to be
> mainly limited to making it harder to capture data from backups or
> file-lifting attacks. Anything that can execute code or commands on the
> host can still get the credentials.
>
>
To be clear I'm not saying not to do this. I think it'd make more sense to
do it via an agent and socket, where libpq learns to ask the agent for
credentials (and certs!). That way we could finally support libnss, etc.
It's not perfect, and it doesn't magically make unattended storage secure,
but it sure helps slow down file-based password theft.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services