Re: md5 passwords and pg_shadow - Mailing list pgsql-hackers

From Neil Conway
Subject Re: md5 passwords and pg_shadow
Date
Msg-id 20020425124813.02ead3db.nconway@klamath.dyndns.org
Whole thread Raw
In response to Re: md5 passwords and pg_shadow  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: md5 passwords and pg_shadow  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: md5 passwords and pg_shadow  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Thu, 25 Apr 2002 01:50:32 -0400 (EDT)
"Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
> Neil Conway wrote:
> > Hi all,
> > 
> > Why does the password_encryption GUC variable default to false?
> > 
> > AFAICT there shouldn't be any issues with client compatibility -- in
> > fact, I'd be inclined to rip out all support for storing cleartext
> > passwords...
> 
> It is false so passwords can be handled by pre-7.2 clients.  Once you
> encrypt them, you can't use passwords on pre-7.2 clients because they
> don't understand the double-md5 hash required.

IMHO, there are two separate processes going on here:
  (1) password storage in pg_shadow
  (2) password submission over the wire

You want to use a hash like MD5 for #1 so that someone who breaks
into the server can't read all the passwords in pg_shadow. You
want to use a hash for #2 so that someone sniffing the network
won't be able to read passwords. Aren't these two goals
orthagonal? In other words, what does the format in which the
password is stored have to do with the format in which data
is sent over the wire?

How about this scheme:

- store all passwords md5 hashed: never store the cleartext
password.
- if the client is using 'password' authentication, they will
send in the cleartext password: MD5 hash it and compare it
with the store MD5 hash. If they match, authentication
succeeds.
- if the client is using 'md5' authentication, use the
existing double-md5 hash technique

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Sequential Scan Read-Ahead
Next
From: Mike Mascari
Date:
Subject: Re: Vote totals for SET in aborted transaction