From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Euler Taveira <euler(at)timbira(dot)com(dot)br>, firoz e v <firoz(dot)ev(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Storing the password in .pgpass file in an encrypted format |
Date: | 2014-02-21 16:08:16 |
Message-ID: | CAMkU=1wdab41eT7tCHSL7gC7grht9A2ThN9-w2qSwzLMu0rz5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>wrote:
> Euler Taveira wrote:
> > On 21-02-2014 09:49, firoz e v wrote:
> > > Even though, there are ways to set the permissions on .pgpass, to
> disallow any access to world or group, the security rules of many
> organizations disallow to hold any kind of passwords, as plain text.
> > >
> > Is your goal hiding the password in .pgpass? You could add support to
> > accept md5... storage format as password.
>
> How would that work? libpq needs the straight password to send to the
> server, not an encrypted one.
It looks like that is the way it is currently written, but it does not have
to be that way, at least for "md5" rather than "password" authentication.
> If you were to have a mechanism by which
> libpq can store an md5'd password (or whatever hash) and send that md5
> to the server and have the server accept it to grant a connection, then
> the md5 has, in effect, become the unencrypted password which others can
> capture from the file, and you're back at square one.
>
The string in .pgpass would be enough for people to log into postgresql,
true. But it would not work to log onto other things which share the same
clear-text password but don't share the same salting mechanism.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2014-02-21 16:16:48 | Re: SPI_connect on multi-threaded app |
Previous Message | Florian Pflug | 2014-02-21 16:04:04 | Re: Uninterruptable regexp_replace in 9.3.1 ? |