Re: MD5 authentication needs help

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> What happened to "possession of the contents of pg_authid is sufficient
> >> to log in"? I thought fixing that was one of the objectives here.
>
> > Yes, it certainly was. I think Bruce was thinking that we could simply
> > hash what goes on to disk with an additional salt that's stored, but
> > that wouldn't actually work without requiring a change to the wireline
> > protocol, which is the basis of this entire line of discussion, in my
> > view.
>
> 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.

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.

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

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

Thanks,

Stephen