MIME-Version: 1.0
References: 
 <CAH7T-aqV9KVuO2yCpzTM2E0Pz=yJOMhK1PyAGt=od77_OztBVg@mail.gmail.com>
 <836EAAF0-1765-4B0F-A145-123464A19255@yesql.se>
In-Reply-To: <836EAAF0-1765-4B0F-A145-123464A19255@yesql.se>
From: Sehrope Sarkuni <sehrope@jackdb.com>
Date: Mon, 25 May 2026 12:11:25 -0400
Message-ID: 
 <CAH7T-areWmFFp2N58bx_fF-xJxZ5KPpPo8HThECoNJf7K_-z0w@mail.gmail.com>
Subject: Re: Tighten SCRAM iteration parsing and bound libpq PBKDF2 work
To: Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000fcc90a0652a6a12a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAH7T-areWmFFp2N58bx_fF-xJxZ5KPpPo8HThECoNJf7K_-z0w%40mail.gmail.com>
Precedence: bulk

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

On Mon, May 25, 2026 at 10:13=E2=80=AFAM Daniel Gustafsson <daniel@yesql.se=
> wrote:

> > On 24 May 2026, at 22:04, Sehrope Sarkuni <sehrope@jackdb.com> wrote:
> > The first patch fixes parsing of SCRAM iteration counts in both the
> backend SCRAM verifier parser and libpq's server-first-message parser.
> Previously both paths parsed into a long and then stored the result in an
> int, so values in (INT_MAX, LONG_MAX] could be accepted by strtol() and
> then narrowed incorrectly. I don't think this allows for any invalid logi=
ns
> as the password verifier would have tried to verify a different iteration
> count, but it's still wrong.
>
> The iteration count parsing you refer to is extracting the iterations fro=
m
> the
> stored password, it's not parsing user input in any way.  The iteration
> count
> in set in the password using scram_sha_256_iterations, which in turn can
> be set
> by the GUC scram_iterations which is limited to 1..INT_MAX (before being
> accessible as a GUC it was hardcoded to 4096).
>
> strtol() to an int without checking if the parsed value exceeds INT_MAX
> isn't
> good code hygiene, and we should fix that, but it cannot in practice caus=
e
> truncation AFAICS.
>
> Can you show a sequence of generating a SCRAM secret which has an iterati=
on
> count outside of 0..INT_MAX, or one which doesn't correspond to the
> setting in
> scram_iterations?
>

You can directly update pg_authid to skip the empty password check
entirely. We do that in pgjdbc to test out connecting against some
nonsensical values.

A regular user can also specify the pre-hashed password in CREATE / ALTER
USER. The server will still try to verify the password to ensure that it is
not an empty string:

// src/backend/commands/user.c#L442
if (password[0] =3D=3D '\0' || plain_crypt_verify(stmt->role, password, "",
&logdetail) =3D=3D STATUS_OK)
{
  ereport(NOTICE,
  (errmsg("empty string is not a valid password, clearing password")));
  new_record_nulls[Anum_pg_authid_rolpassword - 1] =3D true;
}

Normally that would prevent you from trying to create something with a huge
value of iterations as it'd never finish. But the long-to-int overflow
means that it finishes immediately.

postgres=3D# CREATE USER scram_test PASSWORD 'abcd';
CREATE ROLE

# Default of 4096 iterations
postgres=3D# SELECT rolpassword FROM pg_authid WHERE rolname =3D 'scram_tes=
t';
                                                              rolpassword

---------------------------------------------------------------------------=
------------------------------------------------------------
 SCRAM-SHA-256$4096:PTh5Qe4SmvJnUSHsa6CJpg=3D=3D$rbWsmPJVYzgjIwnVfmfZ43A0FR=
0eThILm+TuYpYF4M0=3D:gFahnsW7KHa73RW1Vk/eP6avCOWf1O2LgCW1ZgiRHtw=3D
(1 row)

# This hangs effectively for ever as it's trying 2^31-1 iterations to
verify that it's not empty string
postgres=3D# ALTER USER scram_test PASSWORD
'SCRAM-SHA-256$2147483647:PTh5Qe4SmvJnUSHsa6CJpg=3D=3D$rbWsmPJVYzgjIwnVfmfZ=
43A0FR0eThILm+TuYpYF4M0=3D:gFahnsW7KHa73RW1Vk/eP6avCOWf1O2LgCW1ZgiRHtw=3D';
^C
Cancel request sent
ERROR:  canceling statement due to user request
Time: 4812.007 ms (00:04.812)

# This completes instantly because it overflows and the empty string
password check passes. Trying to connect gives a scram iterations from the
server of "-1".
postgres=3D# ALTER USER scram_test PASSWORD
'SCRAM-SHA-256$2147483648:PTh5Qe4SmvJnUSHsa6CJpg=3D=3D$rbWsmPJVYzgjIwnVfmfZ=
43A0FR0eThILm+TuYpYF4M0=3D:gFahnsW7KHa73RW1Vk/eP6avCOWf1O2LgCW1ZgiRHtw=3D';
ALTER ROLE
Time: 0.773 ms


> > Patches 0003 through 0005 address a separate client-side resource issue=
.
> In a SCRAM exchange, the PBKDF2 iteration count is supplied by the server=
.
> A hostile or misconfigured server can advertise a very large iteration
> count and keep a blocking libpq connection inside scram_SaltedPassword()
> beyond the caller's connect_timeout. The backend has CHECK_FOR_INTERRUPTS=
()
> inside the loop, but the frontend previously had no equivalent.
>
> A server which request the iteration count of the stored secret, whatever
> it
> is, cannot be considered misconfigured or hostile.  A server which sends =
an
> incorrect iteration count in order to reject a connection after causing t=
he
> client to perform CPU work is hostile (but I'd be quite glad if a hostile
> server rejected my connection rather than tricking me into logging in and
> stealing/corrupting data).
>

The attack vector here is a client side denial of service. I previously
submitted this to the security list and it was deemed out of scope (as a
security issue for core) as it's a client side cpu / memory issue. A real
world example of it would be a SaaS or reporting system that connects to
user specified databases. A malicious user who could specify the remote
database host / port (common in that kind of platform) could get the app to
perform the PBKDF2 iterations forever. There's plenty of other things a
malicious server can do as well (e.g., forcing allocation of infinite
memory). So again out of scope for core as a security issue, but still a
problem in specific use cases.


> Making the SCRAM calculation honor the connection timeout sounds like a
> good
> way to address the latter.
>
> > These patches mirror the blocking connection attempt's deadline into
> PGconn, add an optional interrupt callback to the common SCRAM PBKDF2
> helper, and have libpq use that callback to abort once the in-flight
> bl:qaocking connection deadline has expired. The test modifies a SCRAM
> verifier to advertise a very large iteration count and verifies that
> connect_timeout interrupts the PBKDF2 loop.
> >
> > This protection applies to the blocking connection path, such as
> PQconnectdb(). It does not make connect_timeout apply automatically to
> applications driving PQconnectPoll() themselves.
> >
> > I considered passing the connection deadline directly into the SCRAM
> PBKDF2 helper, but used an interrupt callback instead. That keeps the
> common SCRAM code independent of libpq's timeout representation and allow=
s
> the same mechanism to support other frontend abort conditions, such as
> cancellation of an in-progress connection attempt.
>
> Making sure SCRAM secret calculation doesn't exceed connection_timeout
> sounds
> like a good idea.  However, ode shared between frontend and backend shoul=
d
> IMHO
> not have parameters which only work in the frontend.


I suppose it could be enabled for the backend as well. It'd end up being an
additional if-check to skip the NULL arg.

Alternatively the backend could supply CFI/wrapper as the callback. Then
the scram code would not know anything about who's invoking it.


>   I'm also not convinced
> that it's a good idea to add a callback which in your case gets the entir=
e
> PGconn object.  I'd prefer a check more like the CFI we have in the backe=
nd
> code.
>

Is there a front end example of that to look at? Or are you describing
something more general that does not exist yet?

Another issue is the interval for checking.  One point of allowing
> configurable
> iteration counts was to allow constrained low-power IOT platforms to use
> SCRAM
> by using a much lower iteration count.  Only checking for timeout every
> 4096
> iterations might be well past the connection timeout.  Perhaps the
> interval of
> checking should be a function of the iterations sent by the server?
>

The time check itself is relatively cheap compared to the hashing so
lowering it something more fine grained should not matter much. I picked
4096 to match the default scram iterations so it does not even run in the
normal case. Maybe 256?

The SCRAM RFC estimates it taking .5 seconds to run 4096 iterations on 2015
"current mobile handsets". Would figure it to be even less for devices 10+
years later. And connect timeout granularity is in seconds.


> > The attached patch currently uses a default cap of 100K. That is well
> above PostgreSQL's normal SCRAM iteration count (4K), but it is still a
> client-side behavior change for installations using unusually high SCRAM
> iteration counts. For reference, we added a similar patch to pgjdbc with
> the same 100K default.
>
> I am off the cuff -1 on adding more connection parameters for niche
> usecases
> like this (we already have many enough to make it confusing), it will be
> very
> hard to document what an appropriate setting is, and getting it wrong mig=
ht
> mean rejecting connections in err.
>

For additional reference, we added similar parameters to the java driver
pgjdbc and the node driver node-postgres. Both with a 100K limit.

Both also had a bit more of a direct issue with the large values (v.s.
libpq) as the java driver would create a background thread for the login
(which would get pinned to 100% forever with a huge iteration count) and
the node driver would also hang indefinitely (as node is single threaded
and the crypto functions are not interruptible).

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div>On Mon, May 25, 2026 at 10:13=E2=80=AFAM Daniel Gustafsson &=
lt;<a href=3D"mailto:daniel@yesql.se" target=3D"_blank">daniel@yesql.se</a>=
&gt; wrote:</div></div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">&gt; On 24 May 2026, at 22:04, Sehrope Sarkuni &lt=
;<a href=3D"mailto:sehrope@jackdb.com" target=3D"_blank">sehrope@jackdb.com=
</a>&gt; wrote:<br>&gt; The first patch fixes parsing of SCRAM iteration co=
unts in both the backend SCRAM verifier parser and libpq&#39;s server-first=
-message parser. Previously both paths parsed into a long and then stored t=
he result in an int, so values in (INT_MAX, LONG_MAX] could be accepted by =
strtol() and then narrowed incorrectly. I don&#39;t think this allows for a=
ny invalid logins as the password verifier would have tried to verify a dif=
ferent iteration count, but it&#39;s still wrong.<br>
<br>
The iteration count parsing you refer to is extracting the iterations from =
the<br>
stored password, it&#39;s not parsing user input in any way.=C2=A0 The iter=
ation count<br>
in set in the password using scram_sha_256_iterations, which in turn can be=
 set<br>
by the GUC scram_iterations which is limited to 1..INT_MAX (before being<br=
>
accessible as a GUC it was hardcoded to 4096).<br>
<br>
strtol() to an int without checking if the parsed value exceeds INT_MAX isn=
&#39;t<br>
good code hygiene, and we should fix that, but it cannot in practice cause<=
br>
truncation AFAICS.<br>
<br>
Can you show a sequence of generating a SCRAM secret which has an iteration=
<br>
count outside of 0..INT_MAX, or one which doesn&#39;t correspond to the set=
ting in<br>
scram_iterations?<br></blockquote><div><br></div><div>You can directly upda=
te pg_authid to skip the empty password check entirely. We do that in pgjdb=
c to test out connecting against some nonsensical values.<br><br>A regular =
user can also specify the pre-hashed password in CREATE / ALTER USER. The s=
erver will still try to verify the password to ensure that it is not an emp=
ty string:<br><br>// src/backend/commands/user.c#L442<br>if (password[0] =
=3D=3D &#39;\0&#39; || plain_crypt_verify(stmt-&gt;role, password, &quot;&q=
uot;, &amp;logdetail) =3D=3D STATUS_OK)<br>{<br>=C2=A0 ereport(NOTICE,<br>=
=C2=A0 (errmsg(&quot;empty string is not a valid password, clearing passwor=
d&quot;)));<br>=C2=A0 new_record_nulls[Anum_pg_authid_rolpassword - 1] =3D =
true;<br>}<br><br>Normally that would prevent you from trying to create som=
ething with a huge value of iterations as it&#39;d never finish. But the lo=
ng-to-int overflow means that it finishes immediately.<br><br>postgres=3D# =
CREATE USER scram_test PASSWORD &#39;abcd&#39;;<br>CREATE ROLE<br><br># Def=
ault of 4096 iterations<br>postgres=3D# SELECT rolpassword FROM pg_authid W=
HERE rolname =3D &#39;scram_test&#39;;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rolpassword =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<br>--------------------------=
---------------------------------------------------------------------------=
----------------------------------<br>=C2=A0SCRAM-SHA-256$4096:PTh5Qe4SmvJn=
USHsa6CJpg=3D=3D$rbWsmPJVYzgjIwnVfmfZ43A0FR0eThILm+TuYpYF4M0=3D:gFahnsW7KHa=
73RW1Vk/eP6avCOWf1O2LgCW1ZgiRHtw=3D<br>(1 row)<br><br># This hangs effectiv=
ely for ever as it&#39;s trying 2^31-1 iterations to verify that it&#39;s n=
ot empty string<br>postgres=3D# ALTER USER scram_test PASSWORD &#39;SCRAM-S=
HA-256$2147483647:PTh5Qe4SmvJnUSHsa6CJpg=3D=3D$rbWsmPJVYzgjIwnVfmfZ43A0FR0e=
ThILm+TuYpYF4M0=3D:gFahnsW7KHa73RW1Vk/eP6avCOWf1O2LgCW1ZgiRHtw=3D&#39;;<br>=
^C<br>Cancel request sent<br>ERROR: =C2=A0canceling statement due to user r=
equest<br>Time: 4812.007 ms (00:04.812)<br><br># This completes instantly b=
ecause it overflows and the empty string password check passes. Trying to c=
onnect gives a scram iterations from the server of &quot;-1&quot;.<br>postg=
res=3D# ALTER USER scram_test PASSWORD &#39;SCRAM-SHA-256$2147483648:PTh5Qe=
4SmvJnUSHsa6CJpg=3D=3D$rbWsmPJVYzgjIwnVfmfZ43A0FR0eThILm+TuYpYF4M0=3D:gFahn=
sW7KHa73RW1Vk/eP6avCOWf1O2LgCW1ZgiRHtw=3D&#39;;<br>ALTER ROLE<br>Time: 0.77=
3 ms<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
&gt; Patches 0003 through 0005 address a separate client-side resource issu=
e. In a SCRAM exchange, the PBKDF2 iteration count is supplied by the serve=
r. A hostile or misconfigured server can advertise a very large iteration c=
ount and keep a blocking libpq connection inside scram_SaltedPassword() bey=
ond the caller&#39;s connect_timeout. The backend has CHECK_FOR_INTERRUPTS(=
) inside the loop, but the frontend previously had no equivalent.<br>
<br>
A server which request the iteration count of the stored secret, whatever i=
t<br>
is, cannot be considered misconfigured or hostile.=C2=A0 A server which sen=
ds an<br>
incorrect iteration count in order to reject a connection after causing the=
<br>
client to perform CPU work is hostile (but I&#39;d be quite glad if a hosti=
le<br>
server rejected my connection rather than tricking me into logging in and<b=
r>
stealing/corrupting data).<br></blockquote><div><br></div><div>The attack v=
ector here is a client side denial of service. I previously submitted this =
to the security list and it was deemed out of scope (as a security issue fo=
r core) as it&#39;s a client side cpu / memory issue. A real world example =
of it would be a SaaS or reporting system that connects to user specified d=
atabases. A malicious user who could specify the remote database host / por=
t (common in that kind of platform) could get the app to perform the PBKDF2=
 iterations forever. There&#39;s plenty of other things a malicious server =
can do as well (e.g., forcing allocation of infinite memory). So again out =
of scope for core as a security issue, but still a problem in specific use =
cases.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
Making the SCRAM calculation honor the connection timeout sounds like a goo=
d<br>
way to address the latter.<br>
<br>
&gt; These patches mirror the blocking connection attempt&#39;s deadline in=
to PGconn, add an optional interrupt callback to the common SCRAM PBKDF2 he=
lper, and have libpq use that callback to abort once the in-flight bl:qaock=
ing connection deadline has expired. The test modifies a SCRAM verifier to =
advertise a very large iteration count and verifies that connect_timeout in=
terrupts the PBKDF2 loop.<br>
&gt; <br>
&gt; This protection applies to the blocking connection path, such as PQcon=
nectdb(). It does not make connect_timeout apply automatically to applicati=
ons driving PQconnectPoll() themselves.<br>
&gt; <br>
&gt; I considered passing the connection deadline directly into the SCRAM P=
BKDF2 helper, but used an interrupt callback instead. That keeps the common=
 SCRAM code independent of libpq&#39;s timeout representation and allows th=
e same mechanism to support other frontend abort conditions, such as cancel=
lation of an in-progress connection attempt.<br>
<br>
Making sure SCRAM secret calculation doesn&#39;t exceed connection_timeout =
sounds<br>
like a good idea.=C2=A0 However, ode shared between frontend and backend sh=
ould IMHO<br>
not have parameters which only work in the frontend.</blockquote><div><br><=
/div><div>I suppose it could be enabled for the backend as well. It&#39;d e=
nd up being an additional if-check to skip the NULL arg.</div><div><br></di=
v><div>Alternatively the backend could supply CFI/wrapper as the callback. =
Then the scram code would not know anything about who&#39;s invoking it.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=
=A0 I&#39;m also not convinced<br>
that it&#39;s a good idea to add a callback which in your case gets the ent=
ire<br>
PGconn object.=C2=A0 I&#39;d prefer a check more like the CFI we have in th=
e backend<br>
code.<br></blockquote><div><br></div><div>Is there a front end example of t=
hat to look at? Or are you describing something more general that does not =
exist yet?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
Another issue is the interval for checking.=C2=A0 One point of allowing con=
figurable<br>
iteration counts was to allow constrained low-power IOT platforms to use SC=
RAM<br>
by using a much lower iteration count.=C2=A0 Only checking for timeout ever=
y 4096<br>
iterations might be well past the connection timeout.=C2=A0 Perhaps the int=
erval of<br>
checking should be a function of the iterations sent by the server?<br></bl=
ockquote><div><br></div><div>The time check itself is relatively cheap comp=
ared to the hashing so lowering it something more fine grained should not m=
atter much. I picked 4096 to match the default scram iterations so it does =
not even run in the normal case. Maybe 256?</div><div><br></div><div>The SC=
RAM RFC estimates it taking .5 seconds to run 4096 iterations on 2015 &quot=
;current mobile handsets&quot;. Would figure it to be even less for devices=
 10+ years later. And connect timeout granularity is in seconds.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; The attached patch currently uses a default cap of 100K. That is well =
above PostgreSQL&#39;s normal SCRAM iteration count (4K), but it is still a=
 client-side behavior change for installations using unusually high SCRAM i=
teration counts. For reference, we added a similar patch to pgjdbc with the=
 same 100K default.<br>
<br>
I am off the cuff -1 on adding more connection parameters for niche usecase=
s<br>
like this (we already have many enough to make it confusing), it will be ve=
ry<br>
hard to document what an appropriate setting is, and getting it wrong might=
<br>
mean rejecting connections in err.<br></blockquote><div>=C2=A0</div><div>Fo=
r additional reference, we added similar parameters to the java driver pgjd=
bc and the node driver node-postgres. Both with a 100K limit.</div><div><br=
></div><div>Both also had a bit more of a direct issue with the large value=
s (v.s. libpq) as the java driver would create a background thread for the =
login (which would get pinned to 100% forever with a huge iteration count) =
and the node driver would also hang indefinitely (as node is single threade=
d and the crypto functions are not interruptible).</div><div><br></div><div=
 style=3D"font-family:arial">Regards,</div><div style=3D"font-family:arial"=
>-- Sehrope Sarkuni</div><div style=3D"font-family:arial">Founder &amp; CEO=
 | JackDB, Inc. |=C2=A0<a href=3D"https://www.jackdb.com/" target=3D"_blank=
">https://www.jackdb.com/</a></div><div><br></div><div>=C2=A0</div></div></=
div>
</div>
</div>
</div>

--000000000000fcc90a0652a6a12a--