On Sun, Mar 12, 2017 at 5:35 AM, Joe Conway <mail@joeconway.com> wrote:
> On 03/10/2017 02:43 PM, Michael Paquier wrote:
>> Instead of changing the default, I think that we should take this
>> occasion to rename PQencryptPassword to something like
>> PQhashPassword(), and extend it with a method argument to support both
>> md5 and scram. PQencryptPassword could also be marked as deprecated,
>> or let as-is for some time. For \password, we could have another
>> meta-command but that sounds grotty, or just extend \password with a
>> --method argument. Switching the default could happen in another
>> release.
>>
>> A patch among those lines would be a simple, do people feel that this
>> should be part of PG 10?
>
> Seems like it should work in an analogous way to CREATE/ALTER ROLE.
> According to the docs:
>
> 8<----
> ENCRYPTED
> UNENCRYPTED
>
> These key words control whether the password is stored encrypted in
> the system catalogs. (If neither is specified, the default behavior is
> determined by the configuration parameter password_encryption.) If the
> presented password string is already in MD5-encrypted or SCRAM-encrypted
> format, then it is stored encrypted as-is, regardless of whether
> ENCRYPTED or UNENCRYPTED is specified (since the system cannot decrypt
> the specified encrypted password string). This allows reloading of
> encrypted passwords during dump/restore.
> 8<----
>
> 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.
--
Michael
