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