| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bowen Shi <zxwsbg12138(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Add CHECK_FOR_INTERRUPTS in scram_SaltedPassword loop. |
| Date: | 2023-11-22 15:04:07 |
| Message-ID: | 1674901.1700665447@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 22 Nov 2023, at 14:30, Aleksander Alekseev <aleksander(at)timescale(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2023-11-22 15:53:21 | Re: Adding facility for injection points (or probe points?) for more advanced tests |
| Previous Message | Daniel Gustafsson | 2023-11-22 13:59:07 | Re: [PATCH] Add CHECK_FOR_INTERRUPTS in scram_SaltedPassword loop. |