Re: MD5 authentication needs help

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Wed, Mar 4, 2015 at 04:19:00PM -0500, Stephen Frost wrote:
> > > Hm, well, "don't change the wireline protocol" could be another wanna-have
> > > ... but if we want to stop using MD5, that's not really a realistic goal
> > > is it?
> >
> > I'm trying to address both sides of the issue- improve the current
> > situation without breaking existing clients AND provide a new auth
> > method and encourage everyone to move to it as soon as they're able. We
> > can't simply deprecate md5 as that would break pg_upgrade for any users
> > who are currently using it.
>
> Actually, pg_upgrade uses 'trust' and a private socket file, at least on
> Unix. Of course, post-upgrade, users would have trouble logging in.

The post-upgrade trouble logging in is what I was getting at. Of
course, that issue exists with a pg_dump-based approach also, so my
reference to pg_upgrade above wasn't accurate and it shold have been
"would break upgrades for any users who are currently using it."

> > This half of the discussion has been all about improving md5 without
> > breaking the wireline protocol or existing users.
> >
> > The other half of the discussion is about implementing a new
> > password-based authentication based on one of the vetted authentication
> > protocols already in use today (SCRAM or SRP, for example). Using those
> > new authentication protocols would include a move off of the MD5 hashing
> > function, of course. This would also mean breaking the on-disk hash,
> > but that's necessary anyway because what we do there today isn't secure
> > either and no amount of futzing is going to change that.
>
> While I don't like the requirement to use TLS to improve MD5 fix, I also
> don't like the idea of having users go through updating all these
> passwords only to have us implement the _right_ solution in the next
> release. I don't see why it is useful to be patching up MD5 with a TLS
> requirement when we know they should be moving to SCRAM or SRP. If the
> MD5 change was transparent to users/admins, that would be different.

So, TLS *isn't* an actual requirement with the approach that I've
outlined, it's just that if you're not using it then you have a somewhat
larger risk of successful network-based attacks, but then, if you're
not using TLS then you're unlikely to be worried about that vector.

> > I've got nearly zero interest in trying to go half-way on this by
> > designing something that we think is secure which has had no external
> > review or anyone else who uses it. Further, going that route makes me
> > very nervous that we'd decide on certain compromises in order to make
> > things easier for users without actually realising the problems with
> > such an approach (eg: "well, if we use hack X we wouldn't have to
> > change what is stored on disk and therefore we wouldn't break
>
> I am not happy to blindly accept a new security setup without
> understanding exactly what it is trying to fix, which is why I am asking
> all these questions.

I certainly didn't intend to suggest that anyone blindly accept a new
security setup. I don't mind the questions but I do get a bit
frustrated at the suggestions that we can "fix" the md5 auth mechanism
by simply increasing the salt or putting in a better hashing algorithm.
Those are not solutions to this authentication challenge- for that, we
need to look at SCRAM or SRP, where RFCs have been reviewed and
published which outline exactly how they work and why they work the way
they do. I'd certainly encourage everyone interested in this to go look
at those RFCs.

SCRAM - https://tools.ietf.org/html/rfc5802
SRP - https://www.ietf.org/rfc/rfc2945.txt

> > of a transistion would be a lot easier on our users and I'd definitely
> > recommend that we add that with this new authentication mechanism, to
> > address this kind of issue in the future (not to mention that's often
> > asked for..). Password complexity would be another thing we should
> > really add and is also often requested.
>
> I agree our password management could use improvement.

I'm *very* glad to hear that. When I brought it up 10-or-so years ago,
there was very little interest in these kinds of improvements.

> > Frankly, in the end, I don't see us being able to produce something in
> > time for this release unless someone can be dedicated to the effort over
> > the next couple of months, and therefore I'd prefer to improve the
> > current issues with md5 without breaking the wireline protocol than
> > simply do nothing (again).
>
> I am not sure why we have to shove something into 9.5 --- as you said,
> this issue has been known about for 10+ years.

It'd be nice to show that we're being responsive when issues are brought
up, even if they've existed for a long time (because, in the minds of
some, that we've done nothing in 10 years doesn't exactly reflect very
well on us :( ).

> I think we should do what we can to improve MD5 in cases where the
> user/admin needs to take no action, and then move to add a better
> authentication method.

Great, I believe that we're on the same page with this then.

Thanks!

Stephen