On 14/09/17 18:06, Dave Cramer wrote:
On 14 September 2017 at 02:21, Alvaro Hernandez <a...@ongres.com
<mailto:a...@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
<br...@momjian.us <mailto:br...@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
