From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add "password_protocol" connection parameter to libpq |
Date: | 2019-08-09 15:51:19 |
Message-ID: | 609482826475e0063c7d71b2449ae31c0d61b232.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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}[,...]
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.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-08-09 16:13:15 | Re: POC: Cleaning up orphaned files using undo logs |
Previous Message | Tomas Vondra | 2019-08-09 15:18:54 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |