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