Assurance

["Joe St Sauver" <>]

<>
 commented:

#Joe's alternative of blocking login attempts from offending IP
#only is marginally better in foiling DoS by those unable to use or
#spoof multiple IP addresses.

Not sure that's true -- remember, the goal is to limit the ability 
to brute force, while not enabling DDoS of legitimate users.

Assume evil user does a brute force against user jsmith from IPv4 
address a.b.c.d, and attempts against that account from that IP 
get blocked.

That block does NOT impact legitimate login attempts from that same 
user coming from address e.f.g.h -- that's an important anti-DDoS
protection, I think. That protection is absolute unless the attacked
is on the same IP address (e.g., a shared host scenario, or a NAT/PAT
scenario). 

Regarding the multiple IP case...

Use of a farm of open proxies/bots obviously increases the quantity
of total attempts that are possible, but even if you assume use of 
20,000 bots, each such bot would only allow 3 tries in a 15 minute 
window (using the hypothetical values previously suggested), so 
that implies 

24 hrs/day*60 minutes/hr
------------------------  = a 96 "window"/day
15 minutes/"window" 

96 windows/day * 20,000 bots * 3 tries/window = 5,760,000 tries/day

While that might sound like a lot of attempts, and it is, it is still
far too small to be much of a worry assuming you have long passwords drawn
from a rich character set. 

I'd also suggest that if you *are* under a determined distributed
brute force attack of that sort, some might be tempted to expand the
window duration (e.g., instead of using a 15 minute window, you might
increase that to 3 tries in an hour, say), or to employ other protective
measures, if only to shelter the targeted system from getting slammed
by all those attempted connections. 

You also mentioned spoofing: since we're talking TCP connections and 
not UDP connections, spoofing should not be an issue.

Regards,

Joe