| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, peter(dot)eisentraut(at)2ndquadrant(dot)com |
| Subject: | Re: Password identifiers, protocol aging and SCRAM protocol |
| Date: | 2017-01-18 05:30:38 |
| Message-ID: | CAB7nPqQa3QzhP7QNL6ykN5WQkyf1WQ36vuus=71zFEs5gpYKHg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 18, 2017 at 2:23 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> The latest versions document this precisely, but I agree with Peter's concern
> about plain "scram". Suppose it's 2025 and PostgreSQL support SASL mechanisms
> OAUTHBEARER, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and SCRAM-SHA3-512. What
> should the pg_hba.conf options look like at that time? I don't think having a
> single "scram" option fits in such a world.
Sure.
> I see two strategies that fit:
>
> 1. Single "sasl" option, with a GUC, similar to ssl_ciphers, controlling the
> mechanisms to offer.
> 2. Separate options "scram_sha_256", "scram_sha3_512", "oauthbearer", etc.
Or we could have a sasl option, with a mandatory array of mechanisms
to define one or more items, so method entries in pg_hba.conf would
look llke that:
sasl mechanism=scram_sha_256,scram_sha3_512
Users could define different methods in each hba line once a user and
a database map. I am not sure if many people would care about that
though.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2017-01-18 05:40:12 | Re: Assignment of valid collation for SET operations on queries with UNKNOWN types. |
| Previous Message | Michael Paquier | 2017-01-18 05:25:45 | Re: Assignment of valid collation for SET operations on queries with UNKNOWN types. |