Re: SCRAM in the PG 10 release notes
On Tue, Apr 25, 2017 at 10:16 PM, Bruce Momjian <bruce@momjian.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.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.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian <bruce@momjian.us> wrote:
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.
As Postgres ODBC now has a hard dependency with libpq, no actions is
taken from there. At least this makes one driver worth mentioning.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/11/2017 07:03 AM, Michael Paquier wrote:
On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian <bruce@momjian.us> wrote:
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.As Postgres ODBC now has a hard dependency with libpq, no actions is
taken from there. At least this makes one driver worth mentioning.
FWIW, I wrote a patch for the Go driver at https://github.com/lib/pq, to
implement SCRAM. It's awaiting review.
I updated the List of Drivers in the Wiki. I added a few drivers that
were missing, like the ODBC driver, and the pgtclng driver, as well as a
Go and Rust driver that I'm aware of. I reformatted it, and added a
column to indicate whether each driver uses libpq or not.
https://wiki.postgresql.org/wiki/List_of_drivers
There is a similar list in our docs:
https://www.postgresql.org/docs/devel/static/external-interfaces.html
Should we update the list in the docs, adding every driver we know of?
Or curate the list somehow, adding only more popular drivers? Or perhaps
add a link to the Wiki page from the docs?
We can use this list in the Wiki to track which drivers implement SCRAM.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
I updated the List of Drivers in the Wiki. I added a few drivers that
were missing, like the ODBC driver, and the pgtclng driver, as well as a
Go and Rust driver that I'm aware of. I reformatted it, and added a
column to indicate whether each driver uses libpq or not.
There is a similar list in our docs:
https://www.postgresql.org/docs/devel/static/external-interfaces.html
Should we update the list in the docs, adding every driver we know of?
Or curate the list somehow, adding only more popular drivers? Or perhaps
add a link to the Wiki page from the docs?
Certainly, if that list is out of date, we need to do something about it.
ISTM that the list probably doesn't change fast enough that tracking it
in our SGML docs is a huge problem. I think it'd likely be good enough
to just add the missing drivers to the list in the docs. (If you do,
please back-patch that.)
We can use this list in the Wiki to track which drivers implement SCRAM.
+1. That *is* something likely to change faster than we can update
the SGML docs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/05/17 09:20, Heikki Linnakangas wrote:
On 05/11/2017 07:03 AM, Michael Paquier wrote:
On Thu, May 11, 2017 at 11:50 AM, Bruce Momjian <bruce@momjian.us>
wrote: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.As Postgres ODBC now has a hard dependency with libpq, no actions is
taken from there. At least this makes one driver worth mentioning.FWIW, I wrote a patch for the Go driver at https://github.com/lib/pq,
to implement SCRAM. It's awaiting review.I updated the List of Drivers in the Wiki. I added a few drivers that
were missing, like the ODBC driver, and the pgtclng driver, as well as
a Go and Rust driver that I'm aware of. I reformatted it, and added a
column to indicate whether each driver uses libpq or not.https://wiki.postgresql.org/wiki/List_of_drivers
There is a similar list in our docs:
https://www.postgresql.org/docs/devel/static/external-interfaces.html
Should we update the list in the docs, adding every driver we know of?
Or curate the list somehow, adding only more popular drivers? Or
perhaps add a link to the Wiki page from the docs?We can use this list in the Wiki to track which drivers implement SCRAM.
I have just submitted a PR to add SCRAM support for pgjdbc:
https://github.com/pgjdbc/pgjdbc/pull/842
Thread on the pgjdbc-list:
/messages/by-id/95dea232-aeeb-d619-e917-abf32b44ef8a@8kdata.com
Hopefully it will be merged soon, and the list of drivers could
then be updated with this.
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.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.
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Heikki,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1]/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1]: /messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.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), 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.
As for a recommendation in the release notes, maybe something like
"Installations using MD5 authentication are encouraged to switch to
SCRAM-SHA-256, unless using older client programs or drivers that don't
support it yet."
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 14, 2017 at 3:57 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
I updated the list of drivers on the wiki
(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.
Thanks Heikki for updating. Sorry for slacking on this item.
Regarding hte Erlang driver, http://glozer.net/src/epgsql/ and
http://tilleuropa.se/pgsql are dead links, and I have found one erland
driver on github which is rather active:
https://github.com/epgsql/epgsql
This does not use libpq, and it does not support the sasl protocol.
The third driver
(https://code.google.com/archive/p/erlang-psql-driver/) exists but it
is claimed as unmaintained. Wouldn't it be better to just remove all
three from the list and replace them by the github one?
For node-postgres, I would recommend updating the third column to tell
"yes" if libpq is used, and "no" otherwise.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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@momjian.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), 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).
Álvaro
--
Alvaro Hernandez
-----------
OnGres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 14 September 2017 at 02:21, Alvaro Hernandez <aht@ongres.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@momjian.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@postgresintl.com
www.postgresintl.com
On 14/09/17 18:06, Dave Cramer wrote:
On 14 September 2017 at 02:21, Alvaro Hernandez <aht@ongres.com
<mailto:aht@ongres.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@momjian.us <mailto:bruce@momjian.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
On Fri, Sep 15, 2017 at 12:10 AM, Alvaro Hernandez <aht@ongres.com> wrote:
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).
Adding the information that JDBC is able to speak the SASL protocol
with Postgres from version 42.2.0 looks like a good addition to me, so
I added it on the wiki page.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 14, 2017 at 09:57:36AM +0300, 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@momjian.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), 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.As for a recommendation in the release notes, maybe something like
"Installations using MD5 authentication are encouraged to switch to
SCRAM-SHA-256, unless using older client programs or drivers that don't
support it yet."
That sounds reasonable.
This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
update. Refer to the policy on open item ownership:
/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/18/2017 11:13 AM, Noah Misch wrote:
On Thu, Sep 14, 2017 at 09:57:36AM +0300, 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@momjian.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), 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.As for a recommendation in the release notes, maybe something like
"Installations using MD5 authentication are encouraged to switch to
SCRAM-SHA-256, unless using older client programs or drivers that don't
support it yet."That sounds reasonable.
This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
update. Refer to the policy on open item ownership:
/messages/by-id/20170404140717.GA2675809@tornado.leadboat.com
I'm not sure what exactly to do here. Where should we stick that notice?
We could put it in the release notes, where the bullet point about SCRAM
is, but it would be well hidden. If we want to give advice to people who
might not otherwise pay attention, it should go to a more prominent
place. In the "Migration to version 10" section perhaps. Currently, it
only lists incompatibilities, which this isn't. Perhaps put the notice
after the list of incompatibilities (patch attached)?
- Heikki
Attachments:
release-notes-notice-about-scram.patchtext/x-patch; name=release-notes-notice-about-scram.patchDownload
diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index 1a9110614d..015d441376 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -508,6 +508,12 @@
</itemizedlist>
+ <para>
+ Installations using MD5 authentication are encouraged to switch to
+ SCRAM-SHA-256, unless using older client programs or drivers that don't
+ support it yet.
+ </para>
+
</sect2>
<sect2>
Heikki Linnakangas <hlinnaka@iki.fi> writes:
I'm not sure what exactly to do here. Where should we stick that notice?
We could put it in the release notes, where the bullet point about SCRAM
is, but it would be well hidden. If we want to give advice to people who
might not otherwise pay attention, it should go to a more prominent
place. In the "Migration to version 10" section perhaps. Currently, it
only lists incompatibilities, which this isn't. Perhaps put the notice
after the list of incompatibilities (patch attached)?
That seems pretty weird. I don't see a big reason not to just put it with
the bullet point about SCRAM. People who care will notice it there just
fine.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
I'm not sure what exactly to do here. Where should we stick that notice?
We could put it in the release notes, where the bullet point about SCRAM
is, but it would be well hidden. If we want to give advice to people who
might not otherwise pay attention, it should go to a more prominent place.
In the "Migration to version 10" section perhaps. Currently, it only lists
incompatibilities, which this isn't. Perhaps put the notice after the list
of incompatibilities (patch attached)?
I guess I'm late to the party, but I don't see why this is needed at all.
We encourage people to use any and all new features which are appropriate
to them--that is why we implement new features. Why does this feature need
a special invitation?
Cheers,
Jeff
On Wed, Sep 20, 2017 at 6:55 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
I'm not sure what exactly to do here. Where should we stick that notice?
We could put it in the release notes, where the bullet point about SCRAM is,
but it would be well hidden. If we want to give advice to people who might
not otherwise pay attention, it should go to a more prominent place. In the
"Migration to version 10" section perhaps. Currently, it only lists
incompatibilities, which this isn't. Perhaps put the notice after the list
of incompatibilities (patch attached)?I guess I'm late to the party, but I don't see why this is needed at all.
We encourage people to use any and all new features which are appropriate to
them--that is why we implement new features. Why does this feature need a
special invitation?
There have been continuous complains on those lists for the last 5
years or so that MD5 is "weak" and should be avoided. Well, Postgres
is not wrong in the way it uses MD5 in itself, backups including raw
MD5 hashes being more of a problem. But I would think that it is fair
to tell in a louder to such folks that Postgres has actually done
something on the matter.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 19, 2017 at 4:29 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Wed, Sep 20, 2017 at 6:55 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Tue, Sep 19, 2017 at 1:32 PM, Heikki Linnakangas <hlinnaka@iki.fi>
wrote:
I'm not sure what exactly to do here. Where should we stick that notice?
We could put it in the release notes, where the bullet point aboutSCRAM is,
but it would be well hidden. If we want to give advice to people who
might
not otherwise pay attention, it should go to a more prominent place. In
the
"Migration to version 10" section perhaps. Currently, it only lists
incompatibilities, which this isn't. Perhaps put the notice after thelist
of incompatibilities (patch attached)?
I guess I'm late to the party, but I don't see why this is needed at all.
We encourage people to use any and all new features which areappropriate to
them--that is why we implement new features. Why does this feature need
a
special invitation?
There have been continuous complains on those lists for the last 5
years or so that MD5 is "weak" and should be avoided. Well, Postgres
is not wrong in the way it uses MD5 in itself, backups including raw
MD5 hashes being more of a problem. But I would think that it is fair
to tell in a louder to such folks that Postgres has actually done
something on the matter.
People who are stressed out about it but use PostgreSQL anyway will see it
in the release notes and recognize the importance (to them) without being
told. People who don't use PostgreSQL at all due to the issue aren't going
to be reading the release notes anyway. The place to be louder about "this
is now available" is in the announcement and press release, and in the
(currently unwritten) "E.1.1. Overview", not down in the guts.
Meanwhile the people who don't know enough about it to understand why our
use of md5 "is not wrong", will just see "encourage" and "better security"
and then go lock their users and themselves out of their database and have
a generally miserable experience.
I think the proposed invitation is too strong and warning is too weak.
Especially as there seems to be no way to audit server-side what
drivers/versions people are connecting with. You either have to track down
every client and identify the correct binaries and run ldd against them (or
whatever you would have to do on Windows), or just go ahead and break it
and see who calls.
The people who need this don't need to be encouraged to use it, they just
need to know it exists. The people who need to be encouraged are going to
shoot themselves in the foot.
Cheers,
Jeff
On 9/19/17 17:55, Jeff Janes wrote:
I guess I'm late to the party, but I don't see why this is needed at
all. We encourage people to use any and all new features which are
appropriate to them--that is why we implement new features. Why does
this feature need a special invitation?
It's not clear to me how an average user would get from the press
release or release notes to upgrading their installation to use
SCRAM-based authentication and passwords. A little bit more guidance
somewhere would be helpful.
The patch that Heikki posted seemed reasonable to me as a starting
point, but there probably needs to be more "how" information somewhere.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 9:45 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
On 9/19/17 17:55, Jeff Janes wrote:
I guess I'm late to the party, but I don't see why this is needed at
all. We encourage people to use any and all new features which are
appropriate to them--that is why we implement new features. Why does
this feature need a special invitation?It's not clear to me how an average user would get from the press
release or release notes to upgrading their installation to use
SCRAM-based authentication and passwords. A little bit more guidance
somewhere would be helpful.The patch that Heikki posted seemed reasonable to me as a starting
point, but there probably needs to be more "how" information somewhere.
I agree with that.
+ <para>
+ Installations using MD5 authentication are encouraged to switch to
+ SCRAM-SHA-256, unless using older client programs or drivers that don't
+ support it yet.
+ </para>
I think that the addition of a link to
https://wiki.postgresql.org/wiki/List_of_drivers would be appropriate.
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/19/17 21:44, Michael Paquier wrote:
The patch that Heikki posted seemed reasonable to me as a starting
point, but there probably needs to be more "how" information somewhere.I agree with that.
+ <para> + Installations using MD5 authentication are encouraged to switch to + SCRAM-SHA-256, unless using older client programs or drivers that don't + support it yet. + </para> I think that the addition of a link to https://wiki.postgresql.org/wiki/List_of_drivers would be appropriate.
I don't have any expectation that that list will be kept up to date.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 9:42 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
I don't have any expectation that that list will be kept up to date.
Ditto. I suggest removing this as an open item. There's no defect in
the code alleged, and whether there is a defect in the documentation
is a matter of opinion on which not everyone agrees. The open items
list is not a club to force committers to change things in a way that
the person adding it likes better; it is a means for ensuring that
clear defects get addressed in a timely manner so that we can have a
timely release.
In my opinion, it would be useful and appropriate to document
migration instructions. However, I think the burden of doing that in
an appropriate way is on whoever wants it done, not on Heikki, just
like any other change that somebody wants made. Also in my opinion,
it would be inappropriate to encourage people to migrate to SCRAM.
Our job is to provide features, not to admonish users that they must
use them. We could equally well add notes to the documentation
saying:
* Installations using out-of-core logical replication are encouraged
to consider whether our built-in logical replication is now a better
option.
* Installations using table inheritance for partitioning should
consider using the new table partitioning feature instead.
* Installations using btree indexes on wide keys with equality
comparisons only should consider whether hash indexes are now a better
alternative.
But let's not. Let's just do what we're already doing - tell people
what we've got and let them decide whether to use it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 6:42 AM, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
On 9/19/17 21:44, Michael Paquier wrote:
The patch that Heikki posted seemed reasonable to me as a starting
point, but there probably needs to be more "how" information somewhere.I agree with that.
+ <para> + Installations using MD5 authentication are encouraged to switch to + SCRAM-SHA-256, unless using older client programs or drivers thatdon't
+ support it yet. + </para> I think that the addition of a link to https://wiki.postgresql.org/wiki/List_of_drivers would be appropriate.I don't have any expectation that that list will be kept up to date.
I am not confident that it will be either, but what could we ever have more
confidence in being kept up-to-date than something anyone can update which
is hosted on a community asset? If we can't collectively keep it
up-to-date, then shame on us and what hope is there for anything else?
Certainly if it is not linked to from the docs, then it is just that much
less likely to be kept up to date. The problem with it currently is that
it implies anything using libpq supports scram, even though a libpq which
supports scram has not even been released yet.
Cheers,
Jeff
On 9/19/17 20:45, Peter Eisentraut wrote:
On 9/19/17 17:55, Jeff Janes wrote:
I guess I'm late to the party, but I don't see why this is needed at
all. We encourage people to use any and all new features which are
appropriate to them--that is why we implement new features. Why does
this feature need a special invitation?It's not clear to me how an average user would get from the press
release or release notes to upgrading their installation to use
SCRAM-based authentication and passwords. A little bit more guidance
somewhere would be helpful.
Here is a patch that expands the SCRAM documentation a bit, adds more
explanation how the different options are related, and sets some better
links. I think now you can get from the release notes to the relevant
documentation and have enough information on how to put the new features
into use.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-doc-Expand-user-documentation-on-SCRAM.patchtext/plain; charset=UTF-8; name=0001-doc-Expand-user-documentation-on-SCRAM.patch; x-mac-creator=0; x-mac-type=0Download
From 2e7640d9a6d65664721fff8d4acdd3c9289027b0 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 21 Sep 2017 10:33:09 -0400
Subject: [PATCH] doc: Expand user documentation on SCRAM
Explain more about how the different password authentication methods and
the password_encryption settings relate to each other, give some
upgrading advice, and set a better link from the release notes.
---
doc/src/sgml/client-auth.sgml | 122 ++++++++++++++++++++++++++++++++----------
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/release-10.sgml | 2 +-
3 files changed, 95 insertions(+), 31 deletions(-)
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 1b568683a4..f2f7527107 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -916,46 +916,78 @@ <title>Password Authentication</title>
<indexterm>
<primary>MD5</>
</indexterm>
+ <indexterm>
+ <primary>SCRAM</>
+ </indexterm>
<indexterm>
<primary>password</primary>
<secondary>authentication</secondary>
</indexterm>
<para>
- The password-based authentication methods are <literal>scram-sha-256</>,
- <literal>md5</>, and <literal>password</>. These methods operate
- similarly except for the way that the password is sent across the
+ There are several password-based authentication methods. These methods
+ operate similarly but differ in how the users' passwords are stored on the
+ server and how the password provided by a client is sent across the
connection.
</para>
- <para>
- Plain <literal>password</> sends the password in clear-text, and is
- therefore vulnerable to password <quote>sniffing</> attacks. It should
- always be avoided if possible. If the connection is protected by SSL
- encryption then <literal>password</> can be used safely, though.
- (Though SSL certificate authentication might be a better choice if one
- is depending on using SSL).
- </para>
+ <variablelist>
+ <varlistentry>
+ <term><literal>scram-sha-256</literal></term>
+ <listitem>
+ <para>
+ The method <literal>scram-sha-256</> performs SCRAM-SHA-256
+ authentication, as described in
+ <ulink url="https://tools.ietf.org/html/rfc7677">RFC 7677</ulink>. It
+ is a challenge-response scheme that prevents password sniffing on
+ untrusted connections and supports storing passwords on the server in a
+ cryptographically hashed form that is thought to be secure.
+ </para>
+ <para>
+ This is the most secure of the currently provided methods but might not
+ be supported by older client libraries.
+ </para>
+ </listitem>
+ </varlistentry>
- <para>
- <literal>scram-sha-256</> performs SCRAM-SHA-256 authentication, as
- described in
- <ulink url="https://tools.ietf.org/html/rfc7677">RFC 7677</ulink>. It
- is a challenge-response scheme, that prevents password sniffing on
- untrusted connections. It is more secure than the <literal>md5</>
- method, but might not be supported by older clients.
- </para>
+ <varlistentry>
+ <term><literal>md5</literal></term>
+ <listitem>
+ <para>
+ The method <literal>md5</> uses a custom less secure challenge-response
+ mechanism. It prevents password sniffing and avoids storing passwords
+ on the server in plain text, but provides no protection if an attacker
+ manages to steal the password hash from the server. Also, the MD5 hash
+ algorithm is nowadays no longer consider secure against determined
+ attacks. The <literal>md5</literal> method cannot be used with
+ the <xref linkend="guc-db-user-namespace"> feature.
+ </para>
- <para>
- <literal>md5</> allows falling back to a less secure challenge-response
- mechanism for those users with an MD5 hashed password.
- The fallback mechanism also prevents password sniffing, but provides no
- protection if an attacker manages to steal the password hash from the
- server, and it cannot be used with the <xref
- linkend="guc-db-user-namespace"> feature. For all other users,
- <literal>md5</> works the same as <literal>scram-sha-256</>.
- </para>
+ <para>
+ To ease transition from the <literal>md5</literal> method to the newer
+ SCRAM method, if <literal>md5</literal> is specified as a method
+ in <filename>pg_hba.conf</filename> but the user's password in the
+ server is encrypted for SCRAM (see below), then SCRAM-based
+ authentication will automatically be chosen instead.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>password</literal></term>
+ <listitem>
+ <para>
+ The method <literal>password</> sends the password in clear-text, and
+ is therefore vulnerable to password <quote>sniffing</> attacks. It
+ should always be avoided if possible. If the connection is protected by
+ SSL encryption then <literal>password</> can be used safely, though.
+ (Though SSL certificate authentication might be a better choice if one
+ is depending on using SSL).
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<para>
<productname>PostgreSQL</productname> database passwords are
@@ -964,11 +996,43 @@ <title>Password Authentication</title>
catalog. Passwords can be managed with the SQL commands
<xref linkend="sql-createuser"> and
<xref linkend="sql-alterrole">,
- e.g., <userinput>CREATE USER foo WITH PASSWORD 'secret'</userinput>.
+ e.g., <userinput>CREATE USER foo WITH PASSWORD 'secret'</userinput>,
+ or the <application>psql</application>
+ command <literal>\password</literal>.
If no password has been set up for a user, the stored password
is null and password authentication will always fail for that user.
</para>
+ <para>
+ The availability of the different password-based authentication methods
+ depends on how a user's password in the server is encrypted (or hashed,
+ more accurately). This is controlled by the configuration
+ parameter <xref linkend="guc-password-encryption"> at the time the
+ password is set. If a password was encrypted using
+ the <literal>scram-sha-256</literal> setting, then it can be used for the
+ authentication methods <literal>scram-sha-256</literal>
+ and <literal>password</literal> (but password transmission will be in
+ plain text in the latter case). The authentication method
+ specification <literal>md5</literal> will automatically switch to using
+ the <literal>scram-sha-256</literal> method in this case, as explained
+ above, so it will also work in this case. If a password was encrypted
+ using the <literal>md5</literal> setting, then it can be used only for
+ the <literal>md5</literal> and <literal>password</literal> authentication
+ method specifications (again, with the password transmitted in plain text
+ in the latter case). (Previous PostgreSQL releases supported storing the
+ password on the server in plain text. This is no longer possible.) To
+ check the currently stored password hashes, see the system
+ catalog <literal>pg_authid</literal>.
+ </para>
+
+ <para>
+ To upgrade an existing installation from <literal>md5</literal>
+ to <literal>scram-sha-256</literal>, set <literal>password_encryption =
+ 'scram-sha-256'</literal> in <filename>postgresql.conf</filename>, make
+ all users set new passwords, and change the authentication method
+ specifications in <filename>pg_hba.conf</filename>
+ to <literal>scram-sha-256</literal>.
+ </para>
</sect2>
<sect2 id="gssapi-auth">
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 2b6255ed95..a051724d1c 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1198,7 +1198,7 @@ <title>Security and Authentication</title>
<para>
Note that older clients might lack support for the SCRAM authentication
mechanism, and hence not work with passwords encrypted with
- SCRAM-SHA-256.
+ SCRAM-SHA-256. See <xref linkend="auth-password"> for more details.
</para>
</listitem>
</varlistentry>
diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index 2658b73ca6..98912ab3a2 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -1184,7 +1184,7 @@ <title><acronym>Authentication</></title>
2017-04-18 [c727f120f] Rename "scram" to "scram-sha-256" in pg_hba.conf and pas
-->
<para>
- Add <link linkend="auth-pg-hba-conf"><literal>SCRAM-SHA-256</></>
+ Add <link linkend="auth-password"><literal>SCRAM-SHA-256</></>
support for password negotiation and storage (Michael Paquier,
Heikki Linnakangas)
</para>
--
2.14.1
On 9/20/17 15:52, Jeff Janes wrote:
I think that the addition of a link to
<https://wiki.postgresql.org/wiki/List_of_drivers> would be appropriate.
I don't have any expectation that that list will be kept up to date.
I am not confident that it will be either, but what could we ever have
more confidence in being kept up-to-date than something anyone can
update which is hosted on a community asset?
If we put such a list linked from the documentation, we have to keep it
up to date for years, and no one is committing to do that.
I don't think it's our job to maintain lists of which third-party
products are ready to take advantage of new features in PostgreSQL. I
don't see a list of GUIs ready to work with the new partitioning or
monitoring tools ready to work with the new xlog/wal naming. If some
folks want to maintain such lists, that's great, but it's not a release
issue.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/21/2017 07:51 AM, Peter Eisentraut wrote:
On 9/20/17 15:52, Jeff Janes wrote:
I think that the addition of a link to
<https://wiki.postgresql.org/wiki/List_of_drivers> would be appropriate.
I don't have any expectation that that list will be kept up to date.
I am not confident that it will be either, but what could we ever have
more confidence in being kept up-to-date than something anyone can
update which is hosted on a community asset?If we put such a list linked from the documentation, we have to keep it
up to date for years, and no one is committing to do that.I don't think it's our job to maintain lists of which third-party
products are ready to take advantage of new features in PostgreSQL. I
don't see a list of GUIs ready to work with the new partitioning or
monitoring tools ready to work with the new xlog/wal naming. If some
folks want to maintain such lists, that's great, but it's not a release
issue.
Peter is correct.
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 21, 2017 at 7:42 AM, Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
On 9/19/17 20:45, Peter Eisentraut wrote:
On 9/19/17 17:55, Jeff Janes wrote:
I guess I'm late to the party, but I don't see why this is needed at
all. We encourage people to use any and all new features which are
appropriate to them--that is why we implement new features. Why does
this feature need a special invitation?It's not clear to me how an average user would get from the press
release or release notes to upgrading their installation to use
SCRAM-based authentication and passwords. A little bit more guidance
somewhere would be helpful.Here is a patch that expands the SCRAM documentation a bit, adds more
explanation how the different options are related, and sets some better
links. I think now you can get from the release notes to the relevant
documentation and have enough information on how to put the new features
into use.
This looks good to me. Might suggest adding verifying the clients as a
specific step:
"To upgrade an existing installation from md5 to scram-sha-256, verify that
all client software supports it, set password_encryption = 'scram-sha-256'
in postgresql.conf..."
Cheers,
Jeff
On 9/21/17 14:15, Jeff Janes wrote:
This looks good to me. Might suggest adding verifying the clients as a
specific step:"To upgrade an existing installation from md5 to scram-sha-256, verify
that all client software supports it, set password_encryption =
'scram-sha-256' in postgresql.conf..."
I don't think there is a well-defined way of verifying whether all
client software supports it other than making the switch described and
then checking what breaks. So it's a bit of a circular process.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 9/21/17 14:15, Jeff Janes wrote:
Here is a patch that expands the SCRAM documentation a bit, adds more
explanation how the different options are related, and sets some better
links. I think now you can get from the release notes to the relevant
documentation and have enough information on how to put the new features
into use.This looks good to me. Might suggest adding verifying the clients as a
specific step:
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers