Re: MD5 authentication needs help

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +