Re: SCRAM in the PG 10 release notes

From: Alvaro Hernandez <aht(at)ongres(dot)com>
To: Dave Cramer <pg(at)fastcrypt(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:10:04
Message-ID: c804e9ab-33a1-9e78-16fa-e98cdfe69152@ongres.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14/09/17 18:06, Dave Cramer wrote:
>
> On 14 September 2017 at 02:21, Alvaro Hernandez <aht(at)ongres(dot)com
> <mailto: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 <mailto: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/wiki/List_of_drivers
> <https://wiki.postgresql.org/wiki/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

Of course, I wanted to mean with that for other drivers that are
not JDBC (which I don't know whether they sync the versions or they
don't). Thanks for the clarification!

Álvaro

--

Alvaro Hernandez

-----------
OnGres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-09-14 15:10:14 Re: [COMMITTERS] pgsql: Use MINVALUE/MAXVALUE instead of UNBOUNDED for range partition b
Previous Message Robert Haas 2017-09-14 15:06:40 Re: Partition-wise join for join between (declaratively) partitioned tables