Re: [GENERAL] db_user_namespace, md5 and changing passwords - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [GENERAL] db_user_namespace, md5 and changing passwords
Date
Msg-id 491C4586.5020009@hagander.net
Whole thread Raw
In response to Re: [GENERAL] db_user_namespace, md5 and changing passwords  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [GENERAL] db_user_namespace, md5 and changing passwords  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> I am unsure of exactly where this thing hacks into the authentication
>> stream, but is it really only MD5 that fails?
> 
> The problem with md5 is that the username is part of the encryption salt
> for the stored password, so changing it breaks that --- the client will
> hash the password with what it thinks the username is, but the stored
> password in pg_authid is hashed with what the server thinks the username
> is.
> 
> You might be right that some other auth methods have an issue too,
> but md5 is the only one anyone's ever reported a problem with.  That
> might or might not just represent lack of testing.

Right.

But say GSSAPI for example. It will get the username from an external
source, and compare this to whatever the user specified. If we rewrite
what the user specified, we loose.

But maybe you can work around that by using pg_ident.conf, so *both* the
identities gets rewritten.

Not sure I care enough to dive into what it would actually mean. My
guess is that it's very uncommon to use db_user_namespace in any of
these scenarios (in fact I think it's very uncommon to use it at all,
but even more uncommon in these cases)

//Magnus



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq-events windows gotcha
Next
From: Tom Lane
Date:
Subject: Re: pg_filedump for CVS HEAD