Re: Add "password_protocol" connection parameter to libpq

Поиск
Список
Период
Сортировка
От Jonathan S. Katz
Тема Re: Add "password_protocol" connection parameter to libpq
Дата
Msg-id 071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org
обсуждение исходный текст
Ответ на Re: Add "password_protocol" connection parameter to libpq  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Add "password_protocol" connection parameter to libpq  (Heikki Linnakangas <hlinnaka@iki.fi>)
Re: Add "password_protocol" connection parameter to libpq  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On 8/9/19 11:51 AM, Jeff Davis wrote:
> On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
>> Having an 'any' option, as mentioned before, could be an alternative
>> though.
>
> ...
>
>> I agree with the point that there isn't any guarantee that it'll
>> always
>> be clear-cut as to which of two methods is "better".
>>
>> From a user perspective, it seems like the main things are "don't
>> send
>> my password in the clear to the server", and "require channel binding
>> to
>> prove there isn't a MITM".  I have to admit that I like the idea of
>> requiring scram to be used and not allowing md5 though.
>
> So it seems like we are leaning toward:
>
>    password_protocol = any | {plaintext,md5,scram-sha-256,scram-sha-
> 256-plus}[,...]

First, thanks for proposing / working on this, I like the idea! :) Happy
to test/review.

As long as this one can handle the current upgrade path that's in place
for going from md5 to SCRAM (which AIUI it should) this makes sense to
me. As stated above, there is a clear hierarchy.

I would almost argue that "plaintext" shouldn't even be an option...if
you have "any" set (arguably default?) then plaintext is available. With
our currently supported versions + driver ecosystem, I hope no one needs
to support a forced plaintext setup.

>
> Or maybe:
>
>    channel_binding = {disable|prefer|require}
>    password_plaintext = {disable|enable}
>    password_md5 = {disable|enable}
>
> That seems reasonable. It's three options, but no normal use case would
> need to set more than two, because channel binding forces scram-sha-
> 256-plus.

Seems to be a lot to configure. I'm more of a fan of the previous
method; it'd work nicely with how we've presently defined things and
should be easy to put into a DSN/URI/env variable.

Thanks,

Jonathan


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Some memory not freed at the exit of RelationBuildPartitionDesc()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: POC: converting Lists into arrays