Re: Add "password_protocol" connection parameter to libpq - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: Add "password_protocol" connection parameter to libpq
Date
Msg-id 071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org
Whole thread Raw
In response to Re: Add "password_protocol" connection parameter to libpq  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Add "password_protocol" connection parameter to libpq
Re: Add "password_protocol" connection parameter to libpq
List 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


Attachment

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Some memory not freed at the exit of RelationBuildPartitionDesc()
Next
From: Tom Lane
Date:
Subject: Re: POC: converting Lists into arrays