On Wed, Mar 6, 2024 at 12:34 PM Tomas Vondra
<tomas.vondra@enterprisedb.com> 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 delay?
s/DoS/brute-force/, but yeah, that's basically the question at the
heart of my comment. _If_ the point of auth_delay is to tie up
connection slots in order to degrade service during an attack, then I
think this addition works, in the sense that it makes the self-imposed
DoS more draconian the more failures occur.
But I don't know if that's actually the intended goal. For one, I'm
not convinced that the host tracking part buys you anything more in
practice, under that model. And if people are trying to *avoid* the
DoS somehow, then I just really don't understand the feature.
> 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?
Yeah, I think one key point is to apply the delay to both successful
and failed connections. That probably opens up a bunch more questions,
though? It seems like a big change from the previous behavior. An
attacker can still front-load a bunch of connections in parallel. And
the end state of the working feature is probably still slot exhaustion
during an attack, so...
I looked around a bit at other designs. [1] is HTTP-focused, but it
talks about some design tradeoffs. I wonder if flipping the sense of
the host tracking [2], to keep track of well-behaved clients and let
them through the service degradation that we're applying to the
masses, might be more robust. But I don't know how to let those
clients punch through slot exhaustion without a lot more work.
--Jacob
[1] https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks
[2] https://owasp.org/www-community/Slow_Down_Online_Guessing_Attacks_with_Device_Cookies