Re: [HACKERS] scram and \password

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] scram and \password
Дата
Msg-id CAB7nPqR=JqeGdKPdJRUSaG+TKG_FO4GJxhNNHYEd=oRsrhZNyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] scram and \password  (Joe Conway <mail@joeconway.com>)
Ответы Re: [HACKERS] scram and \password  (Joe Conway <mail@joeconway.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Need a builtin way to run all tests faster manner
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] scram and \password