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

Re: md5 passwords and pg_shadow

From: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: md5 passwords and pg_shadow
Date: 2002-04-25 16:48:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 25 Apr 2002 01:50:32 -0400 (EDT)
"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)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
- 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
- if the client is using 'md5' authentication, use the
existing double-md5 hash technique



Neil Conway <neilconway(at)rogers(dot)com>

In response to


pgsql-hackers by date

Next:From: Mike MascariDate: 2002-04-25 17:16:51
Subject: Re: Vote totals for SET in aborted transaction
Previous:From: Bruce MomjianDate: 2002-04-25 15:50:27
Subject: Re: Vote totals for SET in aborted transaction

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