Lockout

[John Hascall]

> A few weeks ago, I asked Luke to think about whether it is really
> necessary to add a "lockout time" attribute for the purposes of account
> lockout.  Because the lockout time attribute is new (the other three
> attributes already exist in the DB schema), it adds additional code
> complexity because it must be represented in TL data.  My idea is that
> you can deduce whether the account is locked out from the fail count,
> and can determine the time of lockout from the last preauth failure
> time.

Our implementation of lockout-n-release does not keep a lockout time,
it imputes the state from lastfailtime and failcount.

It looks like one thing we do differently is we keep
counting failures (it looks like you stop an the lockout
limit?)  For example, given settings: 5-fails and 1 minute
release, we would do:
	fail 1
	fail 2
	fail 3
	fail 4
	fail 5 (locked out)
	return fail for all attempts for 1 minute, but otherwise ignore
	fail 6 (unlocked as the minute is up)
	fail 7
	fail 8
	fail 9
	fail 10 (locked out)
	return fail for all attempts for 1 minute, but otherwise ignore
	fail 11 (unlocked as the minute is up)
		...etc...

	so our code is:
		if (fails && ((fails % limit) == 0)) ...

we do this so we can see which accounts are getting hammered.
(we log the fail count on lockout so our log scanner picks it up
and sends it to Zymon/hoBBit/BB).

John