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