MIME-Version: 1.0
References: <20250112222828.b36hpzm3ulfzlkws@hjp.at> <372571.1736722760@sss.pgh.pa.us>
 <CANzqJaDxwg_zS3LKZPq1Yj_sJV-T_qWT=mCF-ptEOcDHUJ+nzQ@mail.gmail.com> <20250113204100.qpz6qpqrydtvydiq@hjp.at>
In-Reply-To: <20250113204100.qpz6qpqrydtvydiq@hjp.at>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Mon, 13 Jan 2025 20:09:41 -0500
Message-ID: <CANzqJaCuKWr+S8gR3WDFESnep=ogwcqhihSVD5w3BuvXk3GYSw@mail.gmail.com>
Subject: Re: Automatic upgrade of passwords from md5 to scram-sha256
To: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000eaca9a062ba0374d"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaCuKWr%2BS8gR3WDFESnep%3DogwcqhihSVD5w3BuvXk3GYSw%40mail.gmail.com>
Precedence: bulk

--000000000000eaca9a062ba0374d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 13, 2025 at 3:41=E2=80=AFPM Peter J. Holzer <hjp-pgsql@hjp.at> =
wrote:

> On 2025-01-13 12:19:06 -0500, Ron Johnson wrote:
> > On Sun, Jan 12, 2025 at 5:59=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wr=
ote:
> >  [snip]
> >
> >     I think this idea is a nonstarter, TLS or not.  We're generally
> moving
> >     in the direction of never letting the server see cleartext password=
s.
> >     It's already possible to configure libpq to refuse such requests
> >     (see require_auth parameter), although that hasn't been made the
> >     default.
> >
> >
> > ALTER ROLE xxx WITH PASSWORD accepts hashed values, so a client with th=
e
> > SCRAM-SHA algorithm could:
> > 1. remember the password that was just used to log in,
> > 2. generate the new hash,
> > 3. send that as an ALTER ROLE statement.
>
> Modifying the client to re-set the password is actually something I
> thought about. There are some technical unknowns (e.g. is
> PQencryptPasswordConn accessible through ODBC?) and some organisational
> difficulties (e.g. can we get the customers to upgrade to the newest
> version?), but I guess in our case it would be doable. But in general
> changing every to client to upgrade the password doesn't seem feasible.
> Unless maybe you are proposing that libpq should do that? That might
> work, but it probably also shouldn't do it by default.
>

That seems to me to be the fastest way to get the feature out to users.
(JDBC would also need it.)

Then clients like psql, pgAdmin, etc would need to add those calls.

--=20
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

--000000000000eaca9a062ba0374d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jan 13, 2025 at 3:41=E2=80=AFPM P=
eter J. Holzer &lt;<a href=3D"mailto:hjp-pgsql@hjp.at">hjp-pgsql@hjp.at</a>=
&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">On 2025-01-13 12:19:06 -0500, Ron =
Johnson wrote:<br>
&gt; On Sun, Jan 12, 2025 at 5:59=E2=80=AFPM Tom Lane &lt;<a href=3D"mailto=
:tgl@sss.pgh.pa.us" target=3D"_blank">tgl@sss.pgh.pa.us</a>&gt; wrote:<br>
&gt; =C2=A0[snip]<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0I think this idea is a nonstarter, TLS or not.=C2=
=A0 We&#39;re generally moving<br>
&gt;=C2=A0 =C2=A0 =C2=A0in the direction of never letting the server see cl=
eartext passwords.<br>
&gt;=C2=A0 =C2=A0 =C2=A0It&#39;s already possible to configure libpq to ref=
use such requests<br>
&gt;=C2=A0 =C2=A0 =C2=A0(see require_auth parameter), although that hasn=
9;t been made the<br>
&gt;=C2=A0 =C2=A0 =C2=A0default.<br>
&gt; <br>
&gt; <br>
&gt; ALTER ROLE xxx WITH PASSWORD accepts hashed values, so a client with t=
he<br>
&gt; SCRAM-SHA algorithm could:<br>
&gt; 1. remember the password that was just used to log in,<br>
&gt; 2. generate the new hash,=C2=A0<br>
&gt; 3. send that as an ALTER ROLE statement.<br>
<br>
Modifying the client to re-set the password is actually something I<br>
thought about. There are some technical unknowns (e.g. is<br>
PQencryptPasswordConn accessible through ODBC?) and some organisational<br>
difficulties (e.g. can we get the customers to upgrade to the newest<br>
version?), but I guess in our case it would be doable. But in general<br>
changing every to client to upgrade the password doesn&#39;t seem feasible.=
<br>
Unless maybe you are proposing that libpq should do that? That might<br>
work, but it probably also shouldn&#39;t do it by default.<br></blockquote>=
<div><br></div><div>That seems to me to be the fastest way to get the featu=
re out to=C2=A0users.=C2=A0 (JDBC would also need it.)</div><div><br></div>=
<div>Then clients like psql, pgAdmin, etc would need to add those calls.</d=
iv><div><br></div></div><span class=3D"gmail_signature_prefix">-- </span><b=
r><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">Death to &lt;=
Redacted&gt;, and butter sauce.<div>Don&#39;t boil me, I&#39;m still alive.=
<br><div><div>&lt;Redacted&gt; lobster!</div></div></div></div></div></div>

--000000000000eaca9a062ba0374d--