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.
> 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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +