On Wed, Mar 6, 2024 at 12:34 PM Tomas Vondra <tomas.von...@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