On Mon, Nov 27, 2023 at 10:05:49AM +0100, Daniel Gustafsson wrote:
> I don't see any reason to backpatch further down than 16 given how low the
> hardcoded value is set there, scanning the archives I see no complaints about
> it either. As a reference, CREATE ROLE using 4096 iterations takes 14ms
> On 25 Nov 2023, at 02:20, Michael Paquier wrote:
>
> On Thu, Nov 23, 2023 at 11:19:51AM +0300, Aleksander Alekseev wrote:
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 wants a specific password to
>>
> I think that we should backpatch that down to v16 at least where the
> GUC has been introduced as it's more like a nuisance if one sets the
> GUC to an incorrect value, and I'd like to apply the patch this way.
Agreed.
The patch has been submitted in https://commitfest.postgresql.org/46/4671/
On Thu, Nov 23, 2023 at 11:19:51AM +0300, Aleksander Alekseev wrote:
>>> 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 wants a specific password to be
>>> super-hard to brute force then why should we limit that?
Hi,
> > If we want to add CHECK_FOR_INTERRUPTS inside the loop I think a brief
> > comment would be appropriate.
>
> This has been completed in patch v2 and it's ready for review.
Thanks!
> > I don't think it would be useful to limit this at an arbitrary point,
> > iteration
> > count can be se
> 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 wants a specific password to
be
> super-hard to brute force then why should we limit that?
I agree with that. Maybe some users do want a super-hard password.
RFC 7677 and
Daniel Gustafsson writes:
>> On 22 Nov 2023, at 14:30, Aleksander Alekseev
>> 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
> On 22 Nov 2023, at 14:30, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> When the scram_iterations value is set too large, the backend would hang for
>> a long time. And we can't use Ctrl+C to cancel this query, cause the loop
>> don't
>> process signal interrupts.
>>
>> Add CHECK_FOR_INTERRUPT
Hi,
> When the scram_iterations value is set too large, the backend would hang for
> a long time. And we can't use Ctrl+C to cancel this query, cause the loop
> don't
> process signal interrupts.
>
> Add CHECK_FOR_INTERRUPTS within the loop of scram_SaltedPassword
> to handle any signals receive
