From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | marco(dot)vaneck(at)gmail(dot)com |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)enterprisedb(dot)com, craig(at)2ndquadrant(dot)com, jeff(dot)janes(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Have an encrypted pgpass file |
Date: | 2018-08-02 05:59:38 |
Message-ID: | 20180802.145938.125641041.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello.
I have had complaints several times on lack of this kind of
feature.
At Wed, 1 Aug 2018 17:33:39 +0200, Marco van Eck <marco(dot)vaneck(at)gmail(dot)com> wrote in <CAE35ztPKvPE4xA7+jCGY+O5kL_9FtZ-owPDrUpXMvpU168pGgA(at)mail(dot)gmail(dot)com>
> After explaining the patch to a college we identified potentially execution
> of another user when it is defined in as a command parameter. To protect
> agains it I've removed the possibility to pass the 'passcommand'. 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.
Myabe we don't need the new environment variable by just allowing
.pgpass be a script. If we put faith in the security of .pgpass,
this won't be a problem, putting aside what the script actually
does.
> I think this solution is secure enough, shall we solve this feature-request?
>
>
> Regards, Marco
>
> On Tue, Jul 24, 2018 at 4:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Marco van Eck <marco(dot)vaneck(at)gmail(dot)com> writes:
> > > 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. With a simple test it seems the password entered by
> > > the user also stays in memory, since it is able to reset a broken
> > > connection. Finding the password in memory is not trivial, but prevention
> > > is always preferred.
> >
> > > It might be an idea to wipe the password after the login, and
> > decrypt/read
> > > it again if it needs to reconnect. Would this make the solution more
> > > secure? I had a quick look at the code and the patch would stay compact.
> > > Please let me know of doing this would make sense.
> >
> > We're basically not going to accept any added complication that's designed
> > to prevent memory-inspection attacks, because in general that's a waste
> > of effort. All you're doing is (slightly) reducing the attack window.
> >
> > regards, tom lane
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-08-02 08:05:06 | Re: patch to ensure logical decoding errors early |
Previous Message | Yamaji, Ryo | 2018-08-02 05:25:53 | RE: [HACKERS] Cached plans and statement generalization |