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

From Michael Paquier
Subject Re: [HACKERS] scram and \password
Date
Msg-id CAB7nPqR=JqeGdKPdJRUSaG+TKG_FO4GJxhNNHYEd=oRsrhZNyQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] scram and \password  (Joe Conway <mail@joeconway.com>)
Responses Re: [HACKERS] scram and \password  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
On Mon, Mar 13, 2017 at 12:48 AM, Joe Conway <mail@joeconway.com> wrote:
> On 03/11/2017 11:07 PM, Michael Paquier wrote:
>> Having a RLS on pg_authid to allow a user to look at its own password
>> type is an idea.
>
> Given that that is not likely at this stage of the dev cycle, what about
> a special purpose SQL function that returns the password type for the
> current user?

OK, so what about doing the following then:
1) Create pg_role_password_type(oid), taking a role OID in input and
returning the type.
2) Extend PQencryptPassword with a method, and document. Plaintext is forbidden.
3) Extend \password in psql with a similar -method=scram|md5 argument,
and forbid the use of "plain" format.
After thinking about it, extending PQencryptPassword() would lead to
future breakage, which makes it clear to not fall into the trap of
having password_encryption set to scram in the server's as well as in
pg_hba.conf and PQencryptPassword() enforcing things to md5.

> Or is it a security issue of some sort to allow a user to
> know their own password type?

Don't think so. Any user has access to the value of
password_encryption. So one can guess what will be the format of a
password hashed.
-- 
Michael



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] scram and \password