Re: SCRAM in the PG 10 release notes

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Alvaro Hernandez <aht(at)ongres(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SCRAM in the PG 10 release notes
Date: 2017-09-14 15:06:25
Message-ID: CADK3HHK56Pt425qLP9SsaM0N=oPtF9Yv8UiLok6WpPLn=Z8wAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14 September 2017 at 02:21, Alvaro Hernandez <aht(at)ongres(dot)com> wrote:

>
>
> On 14/09/17 08:57, Heikki Linnakangas wrote:
>
>> On 09/12/2017 04:09 AM, Noah Misch wrote:
>>
>>> On Wed, May 10, 2017 at 10:50:51PM -0400, Bruce Momjian wrote:
>>>
>>>> On Mon, May 1, 2017 at 08:12:51AM -0400, Robert Haas wrote:
>>>>
>>>>> On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce(at)momjian(dot)us>
>>>>> wrote:
>>>>>
>>>>>> Well, we could add "MD5 users are encouraged to switch to
>>>>>> SCRAM-SHA-256". Now whether we want to list this as something on the
>>>>>> SCRAM-SHA-256 description, or mention it as an incompatibility, or
>>>>>> under Migration. I am not clear that MD5 is in such terrible shape
>>>>>> that
>>>>>> this is warranted.
>>>>>>
>>>>>
>>>>> I think it's warranted. The continuing use of MD5 has been a headache
>>>>> for some EnterpriseDB customers who have compliance requirements which
>>>>> they must meet. It's not that they themselves necessarily know or
>>>>> care whether MD5 is secure, although in some cases they do; it's that
>>>>> if they use it, they will be breaking laws or regulations to which
>>>>> their business or agency is subject. I imagine customers of other
>>>>> PostgreSQL companies have similar issues. But leaving that aside, the
>>>>> advantage of SCRAM isn't merely that it uses a better algorithm to
>>>>> hash the password. It has other advantages also, like not being
>>>>> vulnerable to replay attacks. If you're doing password
>>>>> authentication, you should really be using SCRAM, and encouraging
>>>>> people to move to SCRAM after upgrading is a good idea.
>>>>>
>>>>> That having been said, SCRAM is a wire protocol break. You will not
>>>>> be able to upgrade to SCRAM unless and until the drivers you use to
>>>>> connect to the database add support for it. The only such driver
>>>>> that's part of libpq; other drivers that have reimplemented the
>>>>> PostgreSQL wire protocol will have to be updated with SCRAM support
>>>>> before it will be possible to use SCRAM with those drivers. I think
>>>>> this should be mentioned in the release notes, too. I also think it
>>>>> would be great if somebody would put together a wiki page listing all
>>>>> the popular drivers and (1) whether they use libpq or reimplement the
>>>>> wire protocol, and (2) if the latter, the status of any efforts to
>>>>> implement SCRAM, and (3) if those efforts have been completed, the
>>>>> version from which they support SCRAM. Then, I think we should reach
>>>>> out to all of the maintainers of those driver authors who aren't
>>>>> moving to support SCRAM and encourage them to do so.
>>>>>
>>>>
>>>> I have added this as an open item because we will have to wait to see
>>>> where we are with driver support as the release gets closer.
>>>>
>>>
>>> With the release near, I'm promoting this to the regular open issues
>>> section.
>>>
>>
>> Thanks.
>>
>> I updated the list of drivers on the wiki (https://wiki.postgresql.org/w
>> iki/List_of_drivers), adding a column for whether the driver supports
>> SCRAM authentication. Currently, the only non-libpq driver that has
>> implemented SCRAM is the JDBC driver. I submitted a patch for the Go
>> driver, but it hasn't been committed yet.
>>
>
> On the JDBC driver, strictly speaking, code has not been released yet.
> It is scheduled for v 42.2.0, and maybe the wiki should also mention from
> what version of the driver it is supported (I guess for all cases, unless
> their versioning would be synced with PostgreSQL's).

We won't by syncing our version numbers with Postgres

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-09-14 15:06:40 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message David Steele 2017-09-14 15:01:06 Re: additional contrib test suites