From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Michael Banck <mbanck@gmx.net>
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 21:34:37 +0100
Message-ID: <c7873369-4c91-4d03-b344-c21085da3122@enterprisedb.com> (raw)
In-Reply-To: <CAOYmi+koiMd58P=k_S7wsLw17chw5g2Y8kc6MHzoOqOOZ9KXdA@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>
<20240306161045.GA3542434@nathanxps13>
<CAOYmi+koiMd58P=k_S7wsLw17chw5g2Y8kc6MHzoOqOOZ9KXdA@mail.gmail.com>
On 3/6/24 19:24, Jacob Champion wrote:
> On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart <nathandbossart@gmail.com> 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, which is arguably a denial-of-service scenario, albeit not a
>> particularly worrisome one.
>
> Maybe I've misunderstood the attack vector, but I thought the point of
> the feature was to deny service when the server is under attack. If we
> don't deny service, what does the feature do?
>
> And I may have introduced a red herring in talking about the number of
> hosts, because an attacker operating from a single host is under no
> obligation to actually wait for the authentication delay. Once we hit
> some short timeout, we can safely assume the password is wrong,
> abandon the request, and open up a new connection. It seems like the
> thing limiting our attack is the number of connection slots, not
> MAX_CONN_RECORDS. Am I missing something crucial?
>
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 delay?
ISTM the problem lies in the fact that we apply the delay only *after*
the failed auth attempt. Which makes sense, because until now we didn't
have any state with information for new connections. But with the new
acr_array, we could check that first, and do the delay before trying to
athenticate, no?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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: tomas.vondra@enterprisedb.com, jacob.champion@enterprisedb.com, nathandbossart@gmail.com, mbanck@gmx.net, ams@toroid.org, zhcheng@ceresdata.com
Subject: Re: [PATCH] Exponential backoff for auth_delay
In-Reply-To: <c7873369-4c91-4d03-b344-c21085da3122@enterprisedb.com>
* 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