Re: [PATCH] Add CHECK_FOR_INTERRUPTS in scram_SaltedPassword loop.

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Bowen Shi <zxwsbg12138(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Add CHECK_FOR_INTERRUPTS in scram_SaltedPassword loop.
Date: 2023-11-23 08:19:51
Message-ID: CAJ7c6TMLeqc6MR76LaJCk3jeBnnX=tuVUE=yv9+k7tkCb-OeYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 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 RFC 5802 don't specify the maximum number of iterations.

That's a fairly good point. However we are not obligated not to
implement everything that is missing in RFC. Also in fact we already
limit the number of iterations to INT_MAX.

If we decide to limit this number even further the actual problem is
to figure out what the new practical limit would be. Regardless of the
chosen number there is a possibility of breaking backward
compatibility for certain users.

For this reason I believe merging the proposed patch would be the
right move at this point. It doesn't make anything worse for the
existing users and solves a potential problem for some of them.

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2023-11-23 08:41:14 Re: patch: improve "user mapping not found" error message
Previous Message Xiang Gao 2023-11-23 08:05:26 RE: CRC32C Parallel Computation Optimization on ARM