Re: MD5 authentication needs help - Mailing list pgsql-hackers

* Bruce Momjian (bruce@momjian.us) wrote:
> On Wed, Mar  4, 2015 at 02:21:51PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > On Wed, Mar  4, 2015 at 01:27:32PM -0500, Stephen Frost wrote:
> > > > This further makes what is sent over the network not directly
> > > > susceptible to a replay attack because the server has multiple values
> > > > available to pick for the salt to use and sends one at random to the
> > > > client, exactly how our current challenge/response replay-prevention
> > > > system works.  The downside is that the number of possible values for
> > > > the server to send to prevent replay attacke is reduced from 2^32 to N.
> > >
> > > OK, I understand now --- by not using a random session salt, you can
> > > store a post-hash of what you receive from the client, preventing the
> > > pg_authid from being resent by a client.  Nice trick, though going from
> > > 2^32 to N randomness doesn't seem like a win.
> >
> > You're only looking at it from the network attack vector angle where
> > clearly that's a reduction in strength.  That is not the only angle and
> > in many environments the network attack vector is already addressed with
> > TLS.
>
> Well, passwords are already addressed by certificate authentication, so
> what's your point?  I think we decided we wanted a way to do passwords
> without requiring network encryption.

It's completely unclear to me what you mean by "passwords are already
addressed by certificate authentication."  Password-based and
certificate-based authentication are two independent mechanisms
available today, and both can be used with TLS.  Certainly the more
common implementation that I've come across is password-based
authentication through the md5 mechanism with TLS.  There are few places
which actually use client-side certificate-based authentication but tons
which use TLS.

> > From the perspective of what everyone is currently complaining about on
> > the web, which is the pg_authid compromise vector, it'd be a huge
> > improvement over the current situation and we wouldn't be breaking any
> > existing clients, nor does it require having the postmaster see the
> > user's cleartext password during authentication (which is a common
> > argument against recommending the 'password' authentication method).
>
> We are not designing only for what people are complaining about today.

I was simply trying to explain what the 'newly discovered' vector
being discussed today is.  I complained about our implementation here 10
years ago and it has come up before this recent wave of complaints since
then, though perhaps with a bit less publicity, but I suspect that's
just because PG is getting popular.

And, no, I'm not suggesting that we design differently because we're now
popular, but I do think we need to address this issue because it's very
clearly an obvious deficiency.  I trust you feel the same as you started
this thread.

I brought up this approach because it avoids breaking the wireline
protocol or forcing everyone to switch to a new authentication method.
Thanks,
    Stephen