Message-ID: <c7873369-4c91-4d03-b344-c21085da3122@enterprisedb.com>
Date: Wed, 6 Mar 2024 21:34:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Exponential backoff for auth_delay
To: Jacob Champion <jacob.champion@enterprisedb.com>,
 Nathan Bossart <nathandbossart@gmail.com>
Cc: Michael Banck <mbanck@gmx.net>, Abhijit Menon-Sen <ams@toroid.org>,
 pgsql-hackers@lists.postgresql.org, =?UTF-8?B?5oiQ5LmL54SV?=
 <zhcheng@ceresdata.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>
Content-Language: en-US
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: 
 <CAOYmi+koiMd58P=k_S7wsLw17chw5g2Y8kc6MHzoOqOOZ9KXdA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c7873369-4c91-4d03-b344-c21085da3122%40enterprisedb.com>
Precedence: bulk


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