Re: Is md5 really more secure than crypt? - Mailing list pgsql-general

Tom Lane wrote:
> 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

Yes, that would be the trick.  Have the client send them something that
when MD5 hashed matches pg_shadow.  But when we randomize the salt, we
lose the ability.

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

It wouldn't have to be cleartext.  You could do some MD5 hashing as we
do now, except send a fixed salt to the client every time.  (Fixed for
that user.)  Then, they can send a single-MD5 hashed version of the
password, the backend md5 hashes it again with a fixed salt and compares
to pg_shadow.  That way, if they see pg_shadow, they can't just play it
back from the client. They would have to see what the client sent, and
then we are back to the need for random salt to prevent playback by
seeing the client communications.

Once you randomize, the backend can't store an encrypted version of the
secret.  The way we do it now, we encrypt with a fixed salt in
pg_shadow, which works fine.  I can't see any way to improve this in a
way that the client couldn't foil by knowing pg_shadow _and_ keeping
that random step in there.

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

Wow, interesting thought.  Actually, we do already support this.  When
you specify 'md5' in pg_hba.conf, you expect the client to double-md5
encrypt the user-supplied password, and this is where knowing pg_shadow
helps an attacker.  All the other authentication methods, including
plaintext password and ssl, expect the password in the clear, and the
backend encrypts and compares to pg_shadow, so this prevents an attacker
who knows pg_shadow from getting in.  (Again, this assumes GUC
encrypted_passwords, which it will be in 7.3)

(Wow, I hope I don't get lots of these "it takes 10 minutes for me to
think of an answer" type of questions at my administration talk at
O'Reilly.  I will have to give a "see me after the talk" answers.)

I wonder if people using SSL should be encouraged to use 'password'
rather than 'md5' in 7.3?  I am sure some admins use SSL and md5
thinking it is more secure, when it is less.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026