Re: reducing our reliance on MD5

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reducing our reliance on MD5
Date: 2015-02-11 17:16:25
Message-ID: 20150211171625.GX3854@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All,

* Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
> On 02/11/2015 05:57 AM, Tom Lane wrote:
> >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.
>
> +1. We should pick a well-documented mechanism with well-understood
> properties, rather than roll our own again.

Agreed (with this and with the overall proposal from Heikki).

> 4. Implement the SASL mechanism "SCRAM". That's a challenge/response
> password scheme, similar to the current MD5 authentication, but with
> better salt and more expensive computation (= more resistance to
> dictionary attacks).

Note that Kerberos/GSSAPI can be implemented through SASL too, which
means we might be able to deprecate and eventually remove the code we
have for that (the only caveat to that is that some the options we
provide may not all be available through SASL; that said, some of the
options we provide shouldn't ever be used in production environments,
so..).

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-02-11 17:17:23 Re: reducing our reliance on MD5
Previous Message Bruce Momjian 2015-02-11 17:02:48 Re: reducing our reliance on MD5