* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.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
Description: Digital signature