Re: MD5 authentication needs help

On Fri, Mar 6, 2015 at 07:02:36PM -0500, Stephen Frost wrote:
> * Bruce Momjian (bruce(at)momjian(dot)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.

Well, right now the server sends a random 32-bit number as session salt,
but due to the birthday problem, that can repeat in ~16k connection
attempts. If we use an incremented counter for each session, we spread
the salt evenly over the entire 32-bit key space, making replays much
more difficult, e.g. 4 billion.

I don't think the client would ever know the number was different from
the random number we used to send.

The big win for this idea is that it requires no client or admin
changes, while your idea of using a new salt does. My personal opinion
is that the 32-bit counter idea improves MD5 replays, and that we are
better off going with an entirely new authentication method to fix the
pg_authid vulnerability.

I think your argument is that if users are using TLS, there is no replay
problem and you want to focus on the pg_authid problem. I think fixing
the pg_authid problem inside MD5 is just too complex and we are better
off creating a new authentication method for that.

The bottom line is we promised MD5 to prevent replay, but not pg_authid
stealing, and if we can improve on what we promised, we should do that
and not hijack MD5 to fix a different problem, particularly because
fixing MD5 for pg_authid requires admin action.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +