Re: Encrypting pg_shadow passwords - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Encrypting pg_shadow passwords
Date
Msg-id 200106151411.f5FEBrf23687@candle.pha.pa.us
Whole thread Raw
In response to Re: Encrypting pg_shadow passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Encrypting pg_shadow passwords  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Encrypting pg_shadow passwords  (Vince Vielhaber <vev@michvhf.com>)
Re: Encrypting pg_shadow passwords  (Jim Mercer <jim@reptiles.org>)
List pgsql-hackers
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > The problem is for older clients.  Do I need to create a new encryption
> > type for this double-encryption?  Seems we do.
> 
> Hmm ... AFAIR that old discussion, backwards compatibility was not
> thought about at all :-(

Yes, clearly.

> > The bigger problem is how usernames encrypted in pg_shadow can be used
> > to perform the old 'crypt' authentication.  We could sent the pg_shadow
> > salt to the client each time, but that leaves snoopers able to replay
> > the dialog to gain authentication because the salt isn't random anymore.
> 
> Clearly not a good idea.

Yep, big problem because they think they are safe but they are not. 
Better to just reject it.

> > Migrating old sites to encrypted pg_shadow passwords should be easy if a
> > trigger on pg_shadow will look for unencrypted INSERTs and encrypt them.
> 
> If encrypting pg_shadow will break the old-style crypt method, then I
> think forcing a conversion via a trigger is unacceptable.  It will have
> to be a DBA choice (at configure time, or possibly initdb?) whether to
> use encryption or not in pg_shadow; accordingly, either crypt or "new
> crypt" auth method will be supported by the server, not both.  But
> client libraries could be built to support both auth methods.

I hate to add initdb options because it may be confusing.  I wonder if
we should have a script that encrypts the pg_shadow entries that can be
run when the administrator knows that there are no old clients left
around.  That way it can be run _after_ initdb.


> > This is unrelated to moving to MD5 encryption, which is another item on
> > our list.
> 
> It may be unrelated in theory, but in practice we should do both at
> the same time to minimize the number of client-library incompatibility
> issues that arise.  I'd suggest that old-style crypt auth continue to
> use the crypt() call forever, while the new-style should be based on
> MD5 not crypt() from the get-go.
> 
> In a release or three we could discontinue support for old-style crypt,
> but I think we must allow a transition period for people to update their
> clients.

Yes, MD5 is something that probably should be done at the same time to
minimize disruption.

Another idea is to ship 7.2 with double-salt available to clients but
not enabled in pg_shadow then enable it in 7.3.

I think the script idea may be best but it will have to be saved
somewhere so once you run it all future password changes are encrypted
in pg_shadow.

--  Bruce Momjian                        |  http://candle.pha.pa.us 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
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Encrypting pg_shadow passwords
Next
From: Tom Lane
Date:
Subject: Re: RE: Row Versioning, for jdbc updateable result sets