Re: BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password - Mailing list pgsql-bugs

From Stephen Frost
Subject Re: BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password
Date
Msg-id 20140507154431.GW2556@tamriel.snowman.net
Whole thread Raw
In response to BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password  (dlo@isam.kiwi)
Responses Re: BUG #10250: pgAdmin III 1.16.1 stores unescaped plaintext password  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-bugs
Ben,

* dlo@isam.kiwi (dlo@isam.kiwi) wrote:
> When storing credentials for connections into ~/.pgpass the credentials is
> stored in delimited plaintext form. Not only is this practise a security
> risk,=20

This isn't a bug, it's intentional, and if it goes against your security
requirements then simply don't do it.  Storing it in .pgpass encrypted
would require a password to either be provided (in which case, just
don't have the password in the pgpass file..) or for the key to be
stored in plain-text somewhere, which would be the same situation.

Perhaps there is a feature request in here somewhere to have an
ssh-agent like daemon, but there simply hasn't been demand for it.

> but when the credential contains the delimiter (colon) it fails to be
> read back out and app responds with "invalid credentials".
>=20
> x.x.x.x:5432:*:username:password:with:colons

Per the fine documentation, you need to escape any such usage with a
backslash.  Please review:

http://www.postgresql.org/docs/9.3/static/libpq-pgpass.html

    Thanks,

        Stephen

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_ctl of postgres 8.4 doesn't behave the same than 9.x when using a custom unix socket path
Next
From: emanuel.calvo@2ndquadrant.com
Date:
Subject: BUG #10255: CREATE COLLATION bug on 9.4