Yeah, but this is the same with any X strikes solution on any other
platform. It's a tradeoff. One would assume that if a DoS were being
played, that other information would be gathered about the person doing a
DoS.
According to that theory, one would also assume securID cards are not safe
from DoS because they lock out after a certain number of tried attempts.
While it is true that it may be a DoS, there are situations where there
are quite a few people using securID cards with this config because they
feel they would rather be locked out and know that someone was doing
something funny than to let a hacker do whatever they want.
In addition, a lock out isn't the only logic you could implement in an X
strikes scenario. You could also consider simply notifying a sysadmin with
a pager so they can logon and start tracking if someone is hacking the
system. A sort of Intrusion Detection System if you will.
I guess it depends on what this guy wants to do. The primary point of my
message was to ask if it is possible to do what I stated as a workaround
to the stateless HTTP problem that Vivek wrote (rather than being a
discourse on whether it is truly the most secure solution for the
requirements).
On Fri, 7 Apr 2000, Mark Imbriaco wrote:
> On Thu, 6 Apr 2000, Gunther Birznieks wrote:
>
> > Vivek,
> >
> > Is it possible that a special auth handler could be written that stores the number
> > of bad authorizations for a userid and the last time of the hit in a DBM file for
> > quick lookup? Then, configure an environment or server variable if the auth screwed
> > up more than 3 times within the last hour (or some other prespecified time)?
> >
> > Although HTTP is stateless, the username would at least tend to remain constant in
> > most cases of hacking or user problems I would think.
>
> That opens up a nasty Denial of Service attack though. All I have to do
> is try to log into the "gunther" account three times in rapid succession
> with a bogus password, and WHAM, the real Gunther is locked out. Granted,
> it's possible to work around this, but the best way is probably going to
> be cookie based like Vivek suggested.
>
> -Mark
>
>
>
