Volker Lendecke wrote:
On Fri, Oct 23, 2009 at 02:15:40PM -0700, Howard Chu wrote:
I'm not sure you're trying to solve the right problem yet. I'm pretty unconvinced that account lockout is a good solution to anything, in general. That's why I added login rate control to the latest ppolicy draft, where the DSA simply starts inserting delays before responding to failed authc attempts. As I see it, rate control can be managed completely within a single DSA and no state ever needs to be replicated outward on any particular schedule. But at the moment I haven't yet thought about how well this will work in all the possible deployment scenarios.
So once again, what's important here is to analyze what are the types of attacks we expect to see, and how particular defense strategies will behave, and how effectively they will fend off those attacks. Until you've outlined the problems, you don't have any framework for designing the solution.
Just a quick comment: The way we understand NT4 is that the failed attempts are counted locally and only the lockout is replicated. This reduces the load a lot.
That's correct. But it also means that in an environment with M DSAs and N failures before lockout, an attacker can potentially get NxM attempts before being stopped. With a count/lockout-only strategy the attacker can reach NxM in a fairly small amount of time, long before any system-wide IDS can react. In many installations this is unacceptable.
Again, this is why IMO delaying failed login attempts is a better defense - limiting the number of attempts an attacker can launch limits the attacker's overall effectiveness. Simple lockouts allow an attacker to quickly plow thru one account and immediately move on to the next; they don't impede an attacker at all. (This is also the same strategy I use in anti-spam filters on SMTP servers - delay the server's response to mail coming from a blacklisted server, rather than rejecting it immediately, and you have effectively slowed the propagation rate of spam on the network.)