Re: Encrypting pg_shadow passwords

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Encrypting pg_shadow passwords
Date: 2001-06-15 14:11:53
Message-ID: 200106151411.f5FEBrf23687@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-06-15 14:21:37 Re: RE: Row Versioning, for jdbc updateable result sets
Previous Message Tom Lane 2001-06-15 14:03:48 Re: Encrypting pg_shadow passwords