On 02/22/2014 12:20 AM, Alvaro Herrera wrote: > Jeff Janes escribió: >> On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera >> <alvhe...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
