Re: Password leakage avoidance - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Password leakage avoidance
Date
Msg-id CADK3HHKy-TYGgvyGnHVshFPTxvNLuD5ZXX9j1ESRhgw2oO6Www@mail.gmail.com
Whole thread Raw
In response to Re: Password leakage avoidance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Dave Cramer
www.postgres.rocks


On Sat, 23 Dec 2023 at 11:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Joe Conway <mail@joeconway.com> writes:
> The attached patch set moves the guts of \password from psql into the
> libpq client side -- PQchangePassword() (patch 0001).

Haven't really read the patch, just looked at the docs, but here's
a bit of bikeshedding:

* This seems way too eager to promote the use of md5.  Surely the
default ought to be SCRAM, full stop.  I question whether we even
need an algorithm parameter.  Perhaps it's a good idea for
future-proofing, but we could also plan that the function would
make its own decisions based on noting the server's version.
(libpq is far more likely to be au courant about what to do than
the calling application, IMO.)

Using the server version has some issues. It's quite possible to encrypt a user password with md5 when the server version is scram. So if you change the encryption then pg_hba.conf would have to be updated to allow the user to log back in. 

Dave

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Assert failure on 'list_member_ptr(rel->joininfo, restrictinfo)'
Next
From: Pavel Stehule
Date:
Subject: Re: Autonomous transactions 2023, WIP