Re: You're on SecurityFocus.com for the cleartext passwords. - Mailing list pgsql-hackers

> I wrote:
> > The main potential hazard I see is portability.  Is crypt(3) available
> > on *all* the platforms Postgres runs on?
> 
> Waitasec, what am I saying?  We already *do* have crypt password
> support, at least on those platforms where crypt(3) is available.
> 
> As near as I can tell, the crypt option transmits an encrypted password
> across the wire (good), but the comparison at the server end is done by
> taking the cleartext password stored in pg_shadow, crypt()ing it on
> the fly, and comparing that to what was sent by the client.
> 
> This does have the advantage that the same pg_shadow entry will support
> both cleartext-password and crypted-password connections, but we could
> get that another way.  Assuming that the server has crypt(), the
> password could be stored always encrypted instead of always not.
> Cleartext-password connections would be handled just by crypting the
> received password before comparing.  (Before you ask, no I don't think
> we should remove the option of cleartext-password connections.  What of
> clients running on platforms with neither crypt() nor anything better
> like Kerberos?  Should they be forced to drop down to no security at
> all?  I think not.)
> 
> This'd take some rejiggering in (at least) CREATE USER and ALTER USER,
> but it seems doable.  I withdraw the complaint about portability...

Yes, agreed.  Doing it in the backend only is the way to go.  We already
have wire crypting.

I think the only problem is moving dumps from on machine to another. 
The crypt version may not exist or be different on different machines.

However, I now remember there was a bigger issue.  I think the actual
password has to be crypted based on the salt used supplied to the
client.  We can't do that based on the crypted version because we don't
know the client can generate that version.

Now, at the time, we were looking at Unix-style crypting of the
password, which is one-way.  This will not work.  We need something that
we can uncrypt in the backend before applying the client-supplied salt
to see if the passwords match.

The goal here was to make wire sniffing unproductive, and because the
server supplied the salt to be used by the client, you can't just
re-use a sniffed password you saw on the wire.

At least this is my recollection of the problem.

--  Bruce Momjian                        |  http://www.op.net/~candle 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,
Pennsylvania19026