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
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 |