Skip site navigation (1) Skip section navigation (2)

Re: Re: Encrypting pg_shadow passwords

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Mercer <jim(at)reptiles(dot)org>
Cc: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Encrypting pg_shadow passwords
Date: 2001-06-26 14:18:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jim and Bruce wrote:
> [ a lot of stuff ]

What this discussion seems to come down to is whether we should take a
backward step in one area of security (security against wire-sniffing)
to take a forward step in another (not storing plaintext passwords).
It seems largely a matter of local conditions which hazard you consider
greater (though I would note that anyone who is able to examine the
contents of pg_shadow has *already* broken into your database).  Anyway,
I doubt anyone will convince anyone else to change sides on that point.

My take on the matter is that we shouldn't invest any more effort in
crypt-based solutions (here crypt means specifically crypt(3), it's
not a generic term).  The future is double encryption using MD5 ---
or s/MD5/more-modern-hash-algorithm-of-your-choice/, the exact choice
is irrelevant to my point.  We ought to get off our duffs and implement
that, then encourage people to migrate their clients ASAP.  The crypt
code will be supported for awhile longer, but strictly as a
backwards-compatibility measure for old clients.  There's no reason to
spend any additional work on it.

For the same reason I don't see any value in the idea of adding
crypt-based double encryption to clients.  We don't really want to
support that over the long run, so why put effort into it?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Frank Ch. EiglerDate: 2001-06-26 14:30:43
Subject: Re: Encrypting pg_shadow passwords
Previous:From: Tom LaneDate: 2001-06-26 13:47:34
Subject: Re: stuck spin lock with many concurrent users

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group