Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Anyway, I wish we could improve it, but am an resigned to the fact we
> can't.
On first glance it seems obvious that *no* scheme could be proof against
the proposed attack. By hypothesis, the attacker has gotten a look at
the contents of pg_shadow --- therefore, he knows everything the
postmaster does about the user's authentication secret(s). How can the
postmaster pose a challenge that the attacker cannot answer, if the
attacker knows just as much as the postmaster?
It could be done if the postmaster's challenge were of the form "send me
something that *hashes to* the secret I have on disk", rather than the
current implementation's "here's a salt, hash the secret with it and
send it back". But as far as I can see, that means sending a cleartext
password across the wire, which is a cure considerably worse than this
disease. I don't see any way to combine that idea with a one-time
hash for wire-security purposes.
The equivalent attack against /etc/passwd would work just as well,
if the attacker could use a version of /bin/login that accepted the
already-crypted password instead of a cleartext password. /bin/login
avoids this difficulty by insisting on a cleartext password; but instead
it opens itself to wire-sniffing.
Interesting thought: perhaps the most secure combination would be MD5
passwords on disk, SSL connection encryption to guard against
wire-sniffing, and a *cleartext* password challenge. Then the attacker
actually has to prove he knows the password, and not just what's on
disk.
The DBA can easily set up pg_hba.conf to require SSL connections and
cleartext password auth. Do we have a setting that allows him to
enforce that all stored passwords must be MD5-crypted? I forget.
regards, tom lane
