* Bruce Momjian (bruce@momjian.us) wrote:
> On Fri, Mar 6, 2015 at 12:50:14PM -0800, Josh Berkus wrote:
> > On 03/06/2015 08:19 AM, Stephen Frost wrote:
> > > Well, server-side, we already have that- have pgbouncer run on the
> > > database server (something which I'm typically in favor of anyway) and
> > > use 'peer'. If it supported TLS then it could use certificates instead.
> > > The question is what to do after the pooler has connected and that's
> > > actually a generic issue which goes beyond poolers and into
> > > applications, basically, "how can I re-authenticate this connection
> > > using a different role." We have SET ROLE, but that gives a lot of
> > > power to the role the pooler logs in as. It'd definitely be neat to
> > > provide a way to use SCRAM or similar to do that re-authentication after
> > > the initial connection.
> >
> > Using pgbouncer on the DB server is common, but less common that using
> > it on an intermediate server or even the app server itself. So anything
> > we create needs to be implementable with all three configurations in
> > some way.
>
> I think the best solution to this would be to introduce a per-cluster
> salt that is used for every password hash. That way, you could not
> replay a pg_authid hash on another server _unless_ you had manually
> assigned the same cluster salt to both servers, or connection pooler.
Wouldn't that break the wireline protocol, unless you used a fixed set
of known challenges? Perhaps I'm not following what you mean by a
cluster-wide salt here.
Thanks,
Stephen