Hi,
On Wed, Mar 20, 2024 at 11:22:12PM +0100, Daniel Gustafsson wrote:
> > On 20 Mar 2024, at 22:21, Jacob Champion
> > wrote:
> >
> > On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
> > wrote:
> >> I think solutions for case 1 and case 2 are necessarily at odds under
> >> the current design,
> On 20 Mar 2024, at 22:21, Jacob Champion
> wrote:
>
> On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
> wrote:
>> I think solutions for case 1 and case 2 are necessarily at odds under
>> the current design, if auth_delay relies on slot exhaustion to do its
>> work effectively. Weakening that
On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
wrote:
> I think solutions for case 1 and case 2 are necessarily at odds under
> the current design, if auth_delay relies on slot exhaustion to do its
> work effectively. Weakening that on purpose doesn't make much sense to
> me; if a DBA is
On Wed, Mar 6, 2024 at 2:45 PM Michael Banck wrote:
> In order to at least make case 2 not worse for exponential backoff, we
> could maybe disable it (and just wait for auth_delay.milliseconds) once
> MAX_CONN_RECORDS is full. In addition, maybe MAX_CONN_RECORDS should be
> some fraction of
On Wed, Mar 6, 2024 at 12:34 PM Tomas Vondra
wrote:
> Doesn't this mean this approach (as implemented) doesn't actually work
> as a protection against this sort of DoS?
>
> If I'm an attacker, and I can just keep opening new connections for each
> auth request, am I even subject to any auth
Hi,
On Wed, Mar 06, 2024 at 09:34:37PM +0100, Tomas Vondra wrote:
> On 3/6/24 19:24, Jacob Champion wrote:
> > On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart
> > wrote:
> >> Assuming you are referring to the case where we run out of free slots in
> >> acr_array, I'm not sure I see that as
On 3/6/24 19:24, Jacob Champion wrote:
> On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart
> wrote:
>> Assuming you are referring to the case where we run out of free slots in
>> acr_array, I'm not sure I see that as desirable behavior. Once you run out
>> of slots, all failed authentication
On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart wrote:
> Assuming you are referring to the case where we run out of free slots in
> acr_array, I'm not sure I see that as desirable behavior. Once you run out
> of slots, all failed authentication attempts are now subject to the maximum
> delay,
On Tue, Mar 05, 2024 at 05:14:46PM -0800, Jacob Champion wrote:
> On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart
> wrote:
>> I don't have a strong opinion about making this configurable, but I do
>> think we should consider making this a hash table so that we can set
>> MAX_CONN_RECORDS much
On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart wrote:
> I don't have a strong opinion about making this configurable, but I do
> think we should consider making this a hash table so that we can set
> MAX_CONN_RECORDS much higher.
I'm curious why? It seems like the higher you make
On Mon, Mar 04, 2024 at 08:42:55PM +0100, Michael Banck wrote:
> On Wed, Feb 21, 2024 at 10:26:11PM +0100, Tomas Vondra wrote:
>> I think it'd be good to consider:
>>
>> - Making the acr_array a hash table, and larger than 50 entries (I
>> wonder if that should be dynamic / customizable by GUC?).
On Mon, Mar 4, 2024 at 4:58 PM Michael Banck wrote:
> Alright, I have changed it so that auth_delay.milliseconds and
> auth_delay.max_milliseconds are the only GUCs, their default being 0. If
> the latter is 0, the former's value is always taken. If the latter is
> non-zero and larger than the
Hi,
On Mon, Mar 04, 2024 at 03:50:07PM -0500, Robert Haas wrote:
> I agree that two GUCs here seems to be one more than necessary, but I
> wonder whether we couldn't just say 0 means no exponential backoff and
> any other value is the maximum time.
Alright, I have changed it so that
On Mon, Mar 4, 2024 at 2:43 PM Michael Banck wrote:
> > 3) Do we actually need the exponential_backoff GUC? Wouldn't it be
> > sufficient to have the maximum value, and if it's -1 treat that as no
> > backoff?
>
> That is a good question, I guess that makes sense.
>
> The next question then is:
Hi,
On Wed, Feb 21, 2024 at 10:26:11PM +0100, Tomas Vondra wrote:
> Thanks for the patch. I took a closer look at v3, so let me share some
> review comments. Please push back if you happen to disagree with some of
> it, some of this is going to be more a matter of personal preference.
Thanks! As
Hi,
Thanks for the patch. I took a closer look at v3, so let me share some
review comments. Please push back if you happen to disagree with some of
it, some of this is going to be more a matter of personal preference.
1) I think it's a bit weird to have two options specifying amount of
time,
At 2024-01-19 15:08:36 +0100, mba...@gmx.net wrote:
>
> I wonder whether maybe auth_delay.max_seconds should either be renamed
> to auth_delay.exponential_backoff_max_seconds (but then it is rather
> long) in order to make it clearer it only applies in that context or
> alternatively just apply to
On Fri, Jan 19, 2024 at 03:08:36PM +0100, Michael Banck wrote:
> I went through your comments (a lot of which pertained to the original
> larger patch I took code from), attached is a reworked version 2.
Oops, we are supposed to be at version 3, attached.
Michael
>From
Hi,
many thanks for the review!
I went through your comments (a lot of which pertained to the original
larger patch I took code from), attached is a reworked version 2.
Other changes:
1. Ignore STATUS_EOF, this led to auth_delay being applied twice (maybe
due to the gss/kerberos auth psql is
At 2024-01-04 08:30:36 +0100, mba...@gmx.net wrote:
>
> +typedef struct AuthConnRecord
> +{
> + charremote_host[NI_MAXHOST];
> + boolused;
> + double sleep_time; /* in milliseconds */
> +} AuthConnRecord;
Do we really need a "used" field
Hi,
On Wed, Dec 27, 2023 at 05:19:54PM +0100, Michael Banck wrote:
> This patch adds exponential backoff so that one can choose a small
> initial value which gets doubled for each failed authentication attempt
> until a maximum wait time (which is 10s by default, but can be disabled
> if so
Hi,
we had a conversation with a customer about security compliance a while
ago and one thing they were concerned about was avoiding brute-force
attemps for remote password guessing. This is should not be a big
concern if reasonably secure passwords are used and increasing SCRAM
iteration count
22 matches
Mail list logo
