Re: MD5 authentication needs help

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