Alvaro,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Josh Berkus (josh@agliodbs.com) wrote:
>
> > > > 3) Using the user name for the MD5 storage salt allows the MD5 stored
> > > > hash to be used on a different cluster if the user used the same
> > > > password.
> > >
> > > This is a feature as well as a bug. For example, pgBouncer relies on
> > > this aspect of md5 auth.
> >
> > It's not a feature and pgBouncer could be made to not rely on this.
>
> 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.
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.
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..
Thanks!
Stephen