Re: MD5 authentication needs help

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> 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.

This isn't a discussion about designing a new authentication method to
replace MD5. I'm not interested in doing that- we should be using one
which has already been designed by experts in that field (just like we'd
prefer they use PG instead of writing their own relational databases).

This is about trying to make the current situation around MD5 better
without breaking existing clients. This proposal, in my view and at
least that of some others, does that. Does it make the md5
authentication method secure? No, but nothing is going to do that
except deprecating it entirely.

Further, to the extent that we can make *common use-cases* of md5-based
authentication better, that's a good thing.

> > 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)

Saying it's "mostly safe" is questionable, at best.

> 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.

Yes, and we have no (PG-based) mechanism to prevent those connection
attempts, which is a pretty horrible situation to be in.

> 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?

The proposal I've been discussing for improving md5 while not breaking
the existing wireline protocol would address 3 and 4 in your list while
making #2 require fewer connection attempts by an attacker (but then
again, with either approach, it's not like it takes a long time on
today's systems to reach the requisite number of attempts to get a
successful login).

I've not seen a detailed explanation of what your proposal is and so I'm
not sure that I can really comment on it since I don't really know what
it is. The comment about "using a random storage salt" doesn't make any
sense since we can't have both a session salt *and* a storage salt, and
the comment about a "longer session salt" implies a break in the
wireline protocol, which goes against the premise of this discussion.

If we're going to break the wireline protocol then we need to go to
SCRAM or some existing, well-defined authentication system and not
something home-grown.

I'd suggest reviewing Heikki's list of attack vectors and the matrix he
built.

Thanks!

Stephen