Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > >> 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)
> > >
> > > The documentation changes highlight that we are going to validate for
> > > most external authentications using the server username, so the external
> > > authentication has to be set up to use that server username. Were the
> > > docs not clear on that? Do I need a mention of db_user_namespace in the
> > > authentication docs?
> >
> > AFAICS, the changes only say MD5 doesn't work. I think it should be made
> > more clear.
> >
> > And yes, it probably makes sense to put it around the authentication
> > docs as well as a warning to people - that's where they'll go looking if
> > something doesn't work.
>
> OK, documentation updated stating that all authentication has to user
> the server username, and added a mention in the client-auth docs too.
Applied to CVS HEAD. Not sure if it should be backpatched so I didn't.
We do have two bug reports for 8.3 but none for earlier releases where
it was also broken.
---
>
> --
> Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
> Index: doc/src/sgml/client-auth.sgml
> ===
> RCS file: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v
> retrieving revision 1.111
> diff -c -c -r1.111 client-auth.sgml
> *** doc/src/sgml/client-auth.sgml 18 Nov 2008 13:10:20 - 1.111
> --- doc/src/sgml/client-auth.sgml 20 Nov 2008 03:56:43 -
> ***
> *** 702,707
> --- 702,709
> If you are at all concerned about password
> sniffing attacks then md5 is preferred.
> Plain password should always be avoided if possible.
> + md5 cannot be used with + linkend="guc-db-user-namespace">.
>
>
>
> Index: doc/src/sgml/config.sgml
> ===
> RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
> retrieving revision 1.195
> diff -c -c -r1.195 config.sgml
> *** doc/src/sgml/config.sgml 11 Nov 2008 02:42:31 - 1.195
> --- doc/src/sgml/config.sgml 20 Nov 2008 03:56:44 -
> ***
> *** 706,711
> --- 706,722
> before the user name is looked up by the server.
>
>
> +
> + db_user_namespace causes the client's and
> + server's user name representation to differ.
> + Authentication checks are always done with the server's user name
> + so authentication methods must be configured for the
> + server's user name, not the client's. Because
> + md5 uses the user name as salt on both the
> + client and server, md5 cannot be used with
> + db_user_namespace.
> +
> +
>
>
>This feature is intended as a temporary measure until a
> Index: src/backend/libpq/auth.c
> ===
> RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
> retrieving revision 1.171
> diff -c -c -r1.171 auth.c
> *** src/backend/libpq/auth.c 18 Nov 2008 13:10:20 - 1.171
> --- src/backend/libpq/auth.c 20 Nov 2008 03:56:44 -
> ***
> *** 371,376
> --- 371,380
> break;
>
> case uaMD5:
> + if (Db_user_namespace)
> + ereport(FATAL,
> +
> (errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
> + errmsg("MD5 authentication is
> not supported when \"db_user_namespace\" is enabled")));
> sendAuthRequest(port, AUTH_REQ_MD5);
> status = recv_and_check_password_packet(port);
> break;
> Index: src/backend/libpq/hba.c
> ===
> RCS file: /cvsroot/pgsql/src/backend/libpq/hba.c,v
> retrieving revision 1.172
> diff -c -c -r1.172 hba.c
> *** src/backend/libpq/hba.c 28 Oct 2008 12:10:43 - 1.172
> --- src/backend/libpq/hba.c 20 Nov 2008 03:56:47 -
> ***
> *** 846,852
> --- 846,861
> else if (strcmp(token, "reject") == 0)
> parsedline->auth_method = uaReject;
> else if (strcmp(token, "md5") == 0)
> + {
> + if (Db_user_namespace)
> + {
> + ereport(LOG,
> + (errcode(ERRCODE_CONFIG_FILE_ERROR),
> +
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Magnus Hagander wrote:
> >> 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)
> >
> > The documentation changes highlight that we are going to validate for
> > most external authentications using the server username, so the external
> > authentication has to be set up to use that server username. Were the
> > docs not clear on that? Do I need a mention of db_user_namespace in the
> > authentication docs?
>
> AFAICS, the changes only say MD5 doesn't work. I think it should be made
> more clear.
>
> And yes, it probably makes sense to put it around the authentication
> docs as well as a warning to people - that's where they'll go looking if
> something doesn't work.
OK, documentation updated stating that all authentication has to user
the server username, and added a mention in the client-auth docs too.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/client-auth.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/client-auth.sgml,v
retrieving revision 1.111
diff -c -c -r1.111 client-auth.sgml
*** doc/src/sgml/client-auth.sgml 18 Nov 2008 13:10:20 - 1.111
--- doc/src/sgml/client-auth.sgml 20 Nov 2008 03:56:43 -
***
*** 702,707
--- 702,709
If you are at all concerned about password
sniffing attacks then md5 is preferred.
Plain password should always be avoided if possible.
+ md5 cannot be used with .
Index: doc/src/sgml/config.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.195
diff -c -c -r1.195 config.sgml
*** doc/src/sgml/config.sgml11 Nov 2008 02:42:31 - 1.195
--- doc/src/sgml/config.sgml20 Nov 2008 03:56:44 -
***
*** 706,711
--- 706,722
before the user name is looked up by the server.
+
+ db_user_namespace causes the client's and
+ server's user name representation to differ.
+ Authentication checks are always done with the server's user name
+ so authentication methods must be configured for the
+ server's user name, not the client's. Because
+ md5 uses the user name as salt on both the
+ client and server, md5 cannot be used with
+ db_user_namespace.
+
+
This feature is intended as a temporary measure until a
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.171
diff -c -c -r1.171 auth.c
*** src/backend/libpq/auth.c18 Nov 2008 13:10:20 - 1.171
--- src/backend/libpq/auth.c20 Nov 2008 03:56:44 -
***
*** 371,376
--- 371,380
break;
case uaMD5:
+ if (Db_user_namespace)
+ ereport(FATAL,
+
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+errmsg("MD5 authentication is
not supported when \"db_user_namespace\" is enabled")));
sendAuthRequest(port, AUTH_REQ_MD5);
status = recv_and_check_password_packet(port);
break;
Index: src/backend/libpq/hba.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/hba.c,v
retrieving revision 1.172
diff -c -c -r1.172 hba.c
*** src/backend/libpq/hba.c 28 Oct 2008 12:10:43 - 1.172
--- src/backend/libpq/hba.c 20 Nov 2008 03:56:47 -
***
*** 846,852
--- 846,861
else if (strcmp(token, "reject") == 0)
parsedline->auth_method = uaReject;
else if (strcmp(token, "md5") == 0)
+ {
+ if (Db_user_namespace)
+ {
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+errmsg("MD5 authentication is not
supported when \"db_user_namespace\" is enabled")));
+ return false;
+ }
parsedline->auth_method = uaMD5;
+ }
else if (strcmp(token, "pam") == 0)
#ifdef USE_PAM
parsedline->auth_method = uaPAM;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Bruce Momjian wrote: > Magnus Hagander wrote: >> Tom Lane wrote: >>> Magnus Hagander <[EMAIL PROTECTED]> 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) > > The documentation changes highlight that we are going to validate for > most external authentications using the server username, so the external > authentication has to be set up to use that server username. Were the > docs not clear on that? Do I need a mention of db_user_namespace in the > authentication docs? AFAICS, the changes only say MD5 doesn't work. I think it should be made more clear. And yes, it probably makes sense to put it around the authentication docs as well as a warning to people - that's where they'll go looking if something doesn't work. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Magnus Hagander wrote: > Tom Lane wrote: > > Magnus Hagander <[EMAIL PROTECTED]> 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) The documentation changes highlight that we are going to validate for most external authentications using the server username, so the external authentication has to be set up to use that server username. Were the docs not clear on that? Do I need a mention of db_user_namespace in the authentication docs? -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Magnus Hagander <[EMAIL PROTECTED]> 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Bruce Momjian wrote: > Magnus Hagander wrote: >>> I have developed the attached patch, which documents the inability to >>> use MD5 with db_user_namespace, and throws an error when it is used: >>> >>> psql: FATAL: MD5 authentication is not supported when >>> "db_user_namespace" is enabled >> IMHO it would be much nicer to detect this when we load pg_hba.conf. >> It's easy to do these days :-P >> >> I don't think we need to worry about the "changed postgresql.conf after >> we changed pg_hba.conf" that much, because we'll always reload >> pg_hba.conf after the main config file. >> >> I'd still leave the runtime check in as well to handle the "loaded one >> but not the other" case, but let's try prevent the user from loading the >> broken config file in the first place.. > > [ Thread moved to hackers. ] > > OK, updated patch attached. > > Looks a lot better. I am unsure of exactly where this thing hacks into the authentication stream, but is it really only MD5 that fails? AFAICS, we rewrite what the user puts into the system *before* we do the authentication. Which I think would break all authentication *except* password (without md5) and trust, more or less. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] db_user_namespace, md5 and changing passwords
Magnus Hagander wrote:
> > I have developed the attached patch, which documents the inability to
> > use MD5 with db_user_namespace, and throws an error when it is used:
> >
> > psql: FATAL: MD5 authentication is not supported when
> > "db_user_namespace" is enabled
>
> IMHO it would be much nicer to detect this when we load pg_hba.conf.
> It's easy to do these days :-P
>
> I don't think we need to worry about the "changed postgresql.conf after
> we changed pg_hba.conf" that much, because we'll always reload
> pg_hba.conf after the main config file.
>
> I'd still leave the runtime check in as well to handle the "loaded one
> but not the other" case, but let's try prevent the user from loading the
> broken config file in the first place..
[ Thread moved to hackers. ]
OK, updated patch attached.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/config.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
retrieving revision 1.195
diff -c -c -r1.195 config.sgml
*** doc/src/sgml/config.sgml 11 Nov 2008 02:42:31 - 1.195
--- doc/src/sgml/config.sgml 11 Nov 2008 18:49:05 -
***
*** 706,711
--- 706,720
before the user name is looked up by the server.
+
+ Keep in mind all authentication checks are done with
+ the server's representation of the user name, not the client's.
+ Because of this, MD5 authentication will not work
+ when db_user_namespace is enabled because the
+ client and server have different representations of the user
+ name.
+
+
This feature is intended as a temporary measure until a
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.170
diff -c -c -r1.170 auth.c
*** src/backend/libpq/auth.c 28 Oct 2008 12:10:43 - 1.170
--- src/backend/libpq/auth.c 11 Nov 2008 18:49:06 -
***
*** 368,373
--- 368,377
break;
case uaMD5:
+ if (Db_user_namespace)
+ ereport(FATAL,
+ (errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+ errmsg("MD5 authentication is not supported when \"db_user_namespace\" is enabled")));
sendAuthRequest(port, AUTH_REQ_MD5);
status = recv_and_check_password_packet(port);
break;
Index: src/backend/libpq/hba.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/hba.c,v
retrieving revision 1.172
diff -c -c -r1.172 hba.c
*** src/backend/libpq/hba.c 28 Oct 2008 12:10:43 - 1.172
--- src/backend/libpq/hba.c 11 Nov 2008 18:49:06 -
***
*** 846,852
--- 846,861
else if (strcmp(token, "reject") == 0)
parsedline->auth_method = uaReject;
else if (strcmp(token, "md5") == 0)
+ {
+ if (Db_user_namespace)
+ {
+ ereport(LOG,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+ errmsg("MD5 authentication is not supported when \"db_user_namespace\" is enabled")));
+ return false;
+ }
parsedline->auth_method = uaMD5;
+ }
else if (strcmp(token, "pam") == 0)
#ifdef USE_PAM
parsedline->auth_method = uaPAM;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
