Re: Have an encrypted pgpass file

From: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>
To: marco(dot)vaneck(at)gmail(dot)com
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Have an encrypted pgpass file
Date: 2018-08-02 09:41:52
Message-ID: CAEzk6ff=YJm+2tYpEXviq5edSnbsYi3m9+mnp_TcyHSM70jO-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 24 Jul 2018 at 11:25, Marco van Eck <marco(dot)vaneck(at)gmail(dot)com> wrote:

> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy,
>

With the greatest of respect, perhaps you need to get auditors who
understand crypto better.​

​Having a user that has the minimal permissions ​to perform the required
tasks with a stored password that only the automation user can read is
perfectly valid. Encrypting it with a key that must (perforce) be
accessible using the same permissions that the user would need in order to
to read the unencrypted password file is no more valid (look up "security
through obscurity").

Perhaps you could make your auditors happier by restricting that user's
permissions to only run a defined function, and make that function do the
work that the automation script wants? So even if the attacker can access
the password he will still only be able to run that function? (You could
even add DOS protection into the function to ensure it's only run so often,
if you were worried about that.)

Geoff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-08-02 09:43:45 Re: New Defects reported by Coverity Scan for PostgreSQL
Previous Message Amit Kapila 2018-08-02 09:41:39 Re: Explain buffers wrong counter with parallel plans