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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
