Re: MD5 authentication needs help - Mailing list pgsql-hackers

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  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +