* 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
signature.asc
Description: Digital signature
