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

From Jeff Janes
Subject Re: [HACKERS] scram and \password
Date
Msg-id CAMkU=1ycRXp4OVf1qFiNs0sjXiGHxae0Ev5DvqsD0OTi=fxzFw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On Tue, Mar 14, 2017 at 3:15 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 03/14/2017 04:47 AM, Tom Lane wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I'm not talking about changing the default, just having it be possible
to use \password with the new system as it was with the old, whatever
exactly we think that means.

Seems to me the intended behavior of \password is to use the best
available practice.  So my guess is that it ought to use SCRAM when
talking to a >= 10.0 server.  What the previous password was ought
to be irrelevant, even if it could find that out which it shouldn't
be able to IMO.

If the server isn't set up to do SCRAM authentication, i.e. there are no "scram" entries in pg_hba.conf,

The method is not part of the pg_hba matching algorithm, so either the first match is scram, or it isn't.  There is no fallback to later entries, as I understand it.
 
and you set yourself a SCRAM verifier, you have just locked yourself out of the system. I think that's a non-starter. There needs to be some more intelligence in the decision.

Right.  And you can lock yourself out of the system going the other way, as well, setting a md5 password when scram is in pg_hba.  Which is how I ended up starting this thread.
 

It would be a lot more sensible, if there was a way to specify in pg_hba.conf, "scram-or-md5". We punted on that for PostgreSQL 10, but perhaps we should try to cram that in, after all.

So the backend for the incipient connection would consult the catalog pg_authid before responding back to the client with an authentication method, as opposed to merely pulling it out of pg_hba?

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner
Next
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions