Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Date
Msg-id 20050421023237.GV29028@ns.snowman.net
Whole thread Raw
In response to Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
* Andrew Dunstan (andrew@dunslane.net) wrote:
> [bugtraq removed - I don't think this belongs there, at least at this stage]

Sure.

> /etc/shadow is supposedly only readable by root (or things that are
> setuid root). If you have root you already own the box. Yet we store
> passwords there hashed with random salt.

Right, exactly.

> My understanding is that Stephen would like a system where clear
> passwords are never stored. He's right in saying that our "encrypted"
> passwords are in effect cleartext, as a malicious client would only ever
> need to know the hashed pw to gain access, and not the original
> cleartext. Of course, adding random salt won't change that, and you are
> quite right in saying that the random salt would have to be sent as part
> of the challenge.

No, adding a random salt wouldn't change that, that's a direct flaw of
the 'md5' mechanism in pg_hba.conf.  However, I can choose not to use
the 'md5' mechanism in pg_hba.conf and can use 'password' instead.
There's not currently an option to say "use a random salt instead of the
username as the salt" for those of us concerned both about people
sniffing the wire and compromising pg_shadow.

> There's a choice between protecting the password over the wire via a
> challenge/response system, and protecting it in storage. Postgres has
> quite reasonably chosen the former. Stephen says "Well, I can protect
> the wire comms via ssh or IPSEC, and I'd like storage protection too."
> That also seems reasonable, although I don't think the sky is really
> falling in.

Right.

> Lastly, I have seen Jan say several times (on IRC) that mission-critical
> DBs should not be exposed to untrusted networks, but always protected by
> appropriate middleware. I could not agree more.

I agree with this also, of course, but there's only so much one can
do and security in layers...
Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: [COMMITTERS] pgsql: Install some slightly realistic cost estimation