Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Another thing we need to keep in mind besides client compatibility
>> is dump/reload compatibility.
> I don't think there's an issue with dump/reload compatibility as far
> as what I proposed, since it only has to do with the authentication
> procedure, not what gets stored in pg_authid. We might have reasons
> for moving that away from MD5 as well, but it's a separate project.
Hm, well, that doesn't really square with your other expressed opinion:
>> Are there other goals?
> I think the goal is "stop using MD5, or at least have an option to not
> use MD5, because people think that's insecure".
As you say, it's quite debatable whether MD5 is or isn't secure enough
given the way we use it, but what's not debatable is that the optics of it
are not very good anymore. However, if we want to shut up the peanut
gallery on this point, we have to get rid of MD5 usage in pg_authid not
just the on-the-wire protocol --- I seriously doubt that the knee jerk
MD5-is-insecure crowd will make any distinction there. So I'm not
following how you're satisfied with a proposal for just the latter.
In any case, my larger point was that given the pain that we're going to
incur here, and the certainly years-long transition interval involved,
it would be foolish to think only about replacing the MD5 algorithm and
not about reconsidering the context we use it in. Stuff like unreasonably
short salt values should be dealt with at the same time.
regards, tom lane
