Re: [HACKERS] scram and \password - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] scram and \password
Date
Msg-id 16350.1489526094@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [HACKERS] scram and \password  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] scram and \password  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] scram and \password  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> On Tue, Mar 14, 2017 at 8:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Why exactly would anyone want "md5 only"?  I should think that "scram
>> only" is a sensible pg_hba setting, if the DBA feels that md5 is too
>> insecure, but I do not see the point of "md5 only" in 2017.  I think
>> we should just start interpreting that as "md5 or better".

> Without md5-only, a user who uses \password to change their password from a
> newer client would lock themselves out of connecting again from older
> clients.  As a conscious decision (either of the DBA or the user) that
> would be OK, but to have it happen by default would be unfortunate.

That's a point, but what it implies is that \password needs some input
from the user about whether to generate a SCRAM or MD5-hashed password.
It would be a fatal error to try to drive that off the auth method
that had been used for the current connection, even if \password had a
way to find that out.  By definition, your concern is about clients
other than the current one, which might well be coming in from other
addresses and getting challenges based on other pg_hba entries.  So
you can't say that "I came in on a SCRAM connection" is sufficient
reason to generate a SCRAM password.

In short, I don't think that argument refutes my position that "md5"
in pg_hba.conf should be understood as allowing SCRAM passwords too.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: [HACKERS] improve comments of snapbuild.c
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Logical replication existing data copy