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 :-(
> 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.
> 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.
> 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.
regards, tom lane
