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

On Tue, Feb 10, 2015 at 9:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 2. We'd have to figure out how to get support for the new algorithms
>> into libpq.  This actually seems a good bit harder than doing it on
>> the server-side, because I don't think libpq has any dynamic loading
>> facilities the way the server does.
>
> If you think libpq is the only problem, or even the main problem,
> on the client side then you have seriously misjudged the situation.
> There are multiple clients that do not use libpq at all, JDBC being
> the poster child here.

We don't want to make things unnecessarily difficult for clients that
implement the wire protocol from scratch, but I don't think it's our
job to tell the owners of other connectors if, or when, they want to
support new authentication methods.  They certainly won't support them
*before* we have server-side support; we can hope that if we add
server-side support, they will follow along.

> 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.

> I think it would be wise to take two steps back and think about what
> the threat model is here, and what we actually need to improve.
> Offhand I can remember two distinct things we might wish to have more
> protection against:
>
> * scraping of passwords off the wire protocol (but is that still
> a threat in an SSL world?).  Better salting practice would do more
> than replacing the algorithm as such for this, IMO.
>
> * scraping of passwords directly from the pg_authid table or from
> a pg_dump dump.  In this case it's not so much that we are worried
> about preventing the scraper from accessing the database (he's
> evidently in already) as that we'd like to prevent him from recovering
> the original cleartext, since the user might've used that same password
> elsewhere.  (Bad user, but nonetheless something we might try to
> protect against.)  Again, more salt seems like it might go a lot further
> than just changing the algorithm.
>
> 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".  Whether those people
are right or not is probably extremely arguable - indeed, I can
imagine your opening salvo here giving rise to vigorous debate about
whether MD5, in the particular way we are using it, is or is not
secure.  The problem is that MD5 has enough weaknesses that, even if
it is actually secure in the way we are using it, some people are not
going to believe that, and are going to think we're bad people for
using it in any way whatsoever.  I'd like to keep those people as
users, whoever is right about the security issues.  The second problem
is that, even if we could convince all of the people who might be
worried about MD5 that their fears are unfounded, a new attack can be
discovered at any time that weakens it still further and renders what
we're doing unsafe.  We shouldn't wait until then to start the
years-long process of weaning ourselves off of it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company