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
Re: Encrypting pg_shadow passwords Re: Encrypting pg_shadow passwords |
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: