Re: reducing our reliance on MD5

On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
>

All discussion seems to be about the protocol, which is also the harder
problem, isn't it?

ISTM that the more *important* thing to fix is the on-disk storage in
pg_authid.

If you actually worry about someone sniffing your network and mounting an
attack against a password, you can use SSL. That means we already have a
way to deal with that, whereas we don't have a way to mitigate the
pg_authid thing. And also, if you are actually worried about someone
sniffing an MD5'ed password, shouldn't you also worry about that same
person sniffing all the *contents* of your database, which the password is
there to protect?

(and in that regard, LDAP and such encryption algorithms send the password
in clear text in that case....)

Seems the risk of someone either lifting pg_authid from disk or by hacking
the system and being postgres, thereby accessing passwords stored somewhere
else, is actually the bigger problem. But also one that should be
reasonably easy (TM) to fix in a backwards compatible way? (just rewrite
with a new hash whenever the password is changed, but keep reading md5
until they are all replaced.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/