From: Nathan Bossart <nathandbossart@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Michael Banck <mbanck@gmx.net>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Abhijit Menon-Sen <ams@toroid.org>
Cc: pgsql-hackers@lists.postgresql.org, 成之焕 <zhcheng@ceresdata.com>
Subject: Re: [PATCH] Exponential backoff for auth_delay
Date: Wed, 6 Mar 2024 10:10:45 -0600
Message-ID: <20240306161045.GA3542434@nathanxps13> (raw)
In-Reply-To: <CAOYmi+=47C8PEXZ8C9xxTRPtTevJgioQxJ3_vvd45rAQXPBy-Q@mail.gmail.com>
References: <658c4eab.050a0220.731ff.011e@mx.google.com>
<65965e9d.050a0220.919a6.f9e1@mx.google.com>
<ZaYimdRlGS5tdzjy@toroid.org>
<65aa8265.170a0220.1ecef.91df@mx.google.com>
<65aa8439.050a0220.31e77.0071@mx.google.com>
<da09dacb-7158-4af1-99f8-6609070b7553@enterprisedb.com>
<65e62440.170a0220.f6a7c.6f7f@mx.google.com>
<20240305215044.GA3538518@nathanxps13>
<CAOYmi+=47C8PEXZ8C9xxTRPtTevJgioQxJ3_vvd45rAQXPBy-Q@mail.gmail.com>
On Tue, Mar 05, 2024 at 05:14:46PM -0800, Jacob Champion wrote:
> On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart <nathandbossart@gmail.com> 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 MAX_CONN_RECORDS,
> the easier it is to put off the brute-force protection. (My assumption
> is that anyone mounting a serious attack is not going to be doing this
> from their own computer; they'll be doing it from many devices they
> don't own -- a botnet, or a series of proxies, or something.)
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, which is arguably a denial-of-service scenario, albeit not a
particularly worrisome one.
I also think the linear search approach artifically constrains the value of
MAX_CONN_RECORDS, so even if a user wanted to bump it up substantially for
their own build, they'd potentially begin noticing the effects of the O(n)
behavior. AFAICT this is really the only reason this value is set so low
at the moment, as I don't think the memory usage or code complexity of a
hash table with thousands of slots would be too bad. In fact, it might
even be simpler to use hash_search() instead of hard-coding linear searches
in multiple places.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, jacob.champion@enterprisedb.com, mbanck@gmx.net, tomas.vondra@enterprisedb.com, ams@toroid.org, zhcheng@ceresdata.com
Subject: Re: [PATCH] Exponential backoff for auth_delay
In-Reply-To: <20240306161045.GA3542434@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox