On Wed, Mar 4, 2015 at 02:46:54PM -0500, Stephen Frost wrote: > > 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.
My point is we can't design a new authentication method to replace MD5 if it doesn't work well without 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. Let me update my list of possible improvements: 1) MD5 makes users feel uneasy (though our usage is mostly safe) 2) The per-session salt sent to the client is only 32-bits, meaning that it is possible to reply an observed MD5 hash in ~16k connection attempts. 3) Using the user name for the MD5 storage salt allows the MD5 stored hash to be used on a different cluster if the user used the same password. 4) Using the user name for the MD5 storage salt allows the MD5 stored hash to be used on the _same_ cluster. 5) Using the user name for the MD5 storage salt causes the renaming of a user to break the stored password. I see your idea of hashing what the client sends to the server is to currect #4? And #2 becomes more of a problem? And my idea of using a random storage salt and longer session salt fix numbers 2 and 3, but not 4? -- 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
