Ted Lemon <[email protected]> writes: > I am still a bit puzzled: how does increasing the number of attackers > help to bypass the throttling mechanism? Why isn't the throttle per > id/password pair, rather than per ip-address/password/id triple?
Why would you throttle per id/password pair? The attacker doesn't try the same pair more than once. That would be pointless. Let me try explaining this from a different direction. Suppose you are an attacker. You have a list of 10,000 common account names, and a list of 10,000 common passwords. You want to try each of those passwords with each of those account names and try to find a combination that works. If you connect from your compromised host and start plowing through the 100 million combinations, after the first few thousand that you try from that host any decent authentication system will go "hey, there are tons of failed authentications from this one IP address" and block all further attempts, successful or not, from that IP address. That's pretty easy to implement. So what the attacker does instead is use their botnet of a million compromised personal computers (that's sadly not really an exaggeration), and has each one of those hosts try 100 combinations and then disconnect. This is now below (or at least near) the threshold for an actual customer typoing their address or password or something, and rate limiting becomes fairly useless as a defense. > Secondarily, if distributed processing makes throttling per id/password > pair difficult, why is it hard to do the botnet IP address matching at > the authentication point? This seems like it would avoid a _lot_ of > extra processing. Chris addressed this quite well in his message. I don't really have much to add to what he already said. The TLDR in case something about that message was confusing is that only the authentication point can block the IP addresses at the authentication point, but you can analyze Received headers to do a bunch of other things, such as determine compromised botnet IP addresses that someone else *didn't* block but that you *do* want to block for *your* service. It improves the scale and flexibility of what you can do by basically giving you more threat intelligence. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
