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
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 |