Re: [PATCH] Add CHECK_FOR_INTERRUPTS in scram_SaltedPassword loop.

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Aleksander Alekseev <aleksander@timescale.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Bowen Shi <zxwsbg12138@gmail.com>
Date: 2023-11-22T15:04:07Z
Lists: pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 22 Nov 2023, at 14:30, Aleksander Alekseev <aleksander@timescale.com> wrote:
>> It sort of makes sense. I wonder though if we should limit the maximum
>> number of iterations instead. If somebody specified 1_000_000+
>> iteration this could also indicate a user error.

> I don't think it would be useful to limit this at an arbitrary point, iteration
> count can be set per password and if someone want a specific password to be
> super-hard to brute force then why should we limit that?

Maybe because it could be used to construct a DOS scenario?  In
particular, since CHECK_FOR_INTERRUPTS doesn't work on the frontend
side, a situation like this wouldn't be interruptible there.

I agree with Aleksander that such cases are much more likely to
indicate user error than anything else.

			regards, tom lane



Commits

  1. Add CHECK_FOR_INTERRUPTS() in scram_SaltedPassword() for the backend