Re: MD5 authentication needs help

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MD5 authentication needs help
Date: 2015-03-05 00:15:15
Message-ID: 20150305001515.GC24491@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

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

> pg_upgrade.."). I'd *much* rather have a clean break and migration
> path for users. If we had a password rotation capability then this kind

Yes, I think we are now saying the same thing.

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

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

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-03-05 00:50:30 a2e35b53 added unused variable to ConversionCreate()
Previous Message Bruce Momjian 2015-03-05 00:00:22 Re: MD5 authentication needs help