* 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.
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).
Thanks,
Stephen