From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: scram and \password |
Date: | 2017-03-11 23:04:10 |
Message-ID: | 75873498-ae3c-9b4f-e462-dc255cf14556@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/11/2017 02:21 PM, Michael Paquier wrote:
> On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
>> So if the password is not already set, \password uses
>> password_encryption to determine which format to use, and if the
>> password is already set, then the current method is assumed.
>
> Yeah, the problem here being that this routine does not need a live
> connection to work, and we surely don't want to make that mandatory,
> that's why I am suggesting something like the above. Another approach
> would be to switch to SCRAM once password_encryption does this switch
> as well... There is no perfect scenario here.
You might extend PQencryptPassword() to take a method. Or create a new
function that does? Certainly psql has a connection available to run the
ALTER ROLE command that it crafts.
I guess a related problem might be, do we have a SQL visible way to
determine what method is used by the current password for a given role?
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-03-11 23:15:45 | Re: scram and \password |
Previous Message | Andres Freund | 2017-03-11 23:00:17 | src/test/regress's check-prepared-txns target |