Re: Storing the password in .pgpass file in an encrypted format

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

like in the RFC 2617 DIGEST-MD5 authentication method used in SASL, or
even CRAM-MD5 (RFC 2195). Both of which are imperfect, but at least not
trivially replayable.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services