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@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
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.
