From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: MD5 authentication needs help |
Date: | 2015-03-06 15:49:02 |
Message-ID: | 20150306154902.GC3291@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > Perhaps one of the requirements of a new auth method should be to allow
> > middlemen such as connection poolers. It's been over two years since I
> > had a look, but IIRC pgbouncer had the very ugly requirement of its own
> > copy of user/passwords in a file, and of course you had to update it
> > separately if you changed the password in the server. We need to make
> > it possible for it not to require any such thing.
>
> If we go this direction, we've got to be *very* careful that it's only
> when the admin enables it. man-in-the-middle attacks are quite real and
> you're essentially asking that we support them intentionally. I agree
> that we want to support connection poolers but they have an inherent
> MITM profile.
Sure. I was thinking we would have some mechanism to authenticate the
connection as coming from a pooler that has been previously authorized;
something simple as a new pg_hba.conf entry type for "poolers" that are
only authorized to connect to such-and-such databases, perhaps limit to
such-and-such users, etc.
> Note that this is also something which is up to the pooling system and
> which we can't control. A good example is Kerberos. Kerberos has had a
> way for authentication to be proxied for a long time (with some controls
> to say which principals are allowed to be proxied, and which systems are
> allowed to proxy on behalf of other principals), but pgbouncer doesn't
> support that even though it'd eliminate the need for it to have a user /
> password file.
True.
I think Kerberos implementations are uncommon, and the complexity of
getting the whole thing up and running is probably the major reason; or
at least there's the common belief that it's so.
My guess is that since there are few users, pgbouncer devs see little
reason to implement it also. Chicken and egg, perhaps.
(Actually, is pgbouncer under active maintenance at all these days?)
> Also, I don't expect we're going to remove md5 any time soon and,
> frankly, people using pgbouncer probably aren't worried about the issues
> which exist with that mechanism and care much more about performance, as
> it doesn't even support TLS..
I think the accept the issues because they have no other choice, not
because they are really all that OK with them.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-03-06 15:57:31 | Re: File based Incremental backup v8 |
Previous Message | Adam Brightwell | 2015-03-06 15:36:25 | Re: CATUPDATE confusion? |