| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Marco van Eck <marco(dot)vaneck(at)gmail(dot)com> |
| Cc: | 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-07-24 14:00:21 |
| Message-ID: | 1772.1532440821@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-07-24 14:14:34 | Re: FailedAssertion on partprune |
| Previous Message | Daniel Verite | 2018-07-24 13:58:45 | Re: Stored procedures and out parameters |