From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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 17:28:50 |
Message-ID: | CAMkU=1xq=mMwCxWak2MNuqCf7Kf3tSeTqarcejc5X4xvufXugg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 21, 2014 at 8:42 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 02/22/2014 12:20 AM, Alvaro Herrera wrote:
> > Jeff Janes escribió:
> >> On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera <
> alvherre(at)2ndquadrant(dot)com>wrote:
> >
> >>> 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.
> >
> > That's true. Patches welcome to improve that. Maybe we can define that
> > if the stored password string starts with $1$md5$ and has a just the
> > right length then it's a md5 hash rather than cleartext, or something
> > like that.
>
> Frankly, that it's possible to just replay the md5 password says that
> "md5" isn't really meaningfully better than cleartext, just marginally
> less convenient.
>
> It should really involve a handshake, along the broad lines of:
>
> - Server sends random cookie
> - Client hashes password cleartext with random cookie from server
> - Server hashes stored (cleartext) password with random cookie
> - Server compares values
>
I think that is what it does, except both the client and server use a hash
of password to add the cookie to, not directly the cleartext password. The
server can optionally store the 1st level hash rather than the cleartext,
and then skip the first hash step (but not the second hash step). The
client does not have a mechanism to start out with the hash, it currently
always starts with the cleartext, but that is just an implementation detail.
So it is not replayable if you just see what goes over the wire. If you
see what the client starts with, then it is "replayable" but that is not
really the right word for it.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-02-21 18:42:24 | Re: Storing the password in .pgpass file in an encrypted format |
Previous Message | Tomas Vondra | 2014-02-21 17:11:14 | Re: Storing the password in .pgpass file in an encrypted format |