* Bruce Momjian (br...@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
signature.asc
Description: Digital signature
