Re: reducing our reliance on MD5 - Mailing list pgsql-hackers

On Wed, Feb 11, 2015 at 10:31 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Wed, Feb 11, 2015 at 4:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> 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.
>
>
>
> 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.

Problem with all challenge-response authentication protocols, is that
the hash you have stored has to match the hash you use on the wire
protocol.

It's not like you can store a SHA and provide MD5 authentication.

In essence, it makes making it pluggable or doing both changes
separately as two separate improvements more difficult.