On Wed, Mar 4, 2015 at 02:21:51PM -0500, Stephen Frost wrote: > * 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.
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers