Re: THREE STRIKES...

[Jeffrey W. Baker]

On Sat, 8 Apr 2000, Nicolas MONNET wrote:

> On Fri, 7 Apr 2000, Ask Bjoern Hansen wrote:
> 
> |And the other way around, there is three gazillion open proxies you can
> |abuse to make requests from different ip addresses.
> |
> |Or a determined attacker might have a lot of different local ip addresses
> |at his disposal he can make requests from.
> 
> Let's be realistic on this one: if the idea is to prevent brute force
> attacks, the fact that the attacker might use a few dozens or for that
> matter a few hundreds IPs won't matter much. 

Yes, let's be realistic.  IP tracking is totally ruled out by the AOLs and
Mindsprings of the world.  All of their millions of customers come through
the same proxy farms with the same handful of IP addresses.  That means
that you can't throttle requests on an requests-from-ip/second basis.

Use cookies or URL munging.

-jwb

Re: THREE STRIKES...

[Nicolas MONNET]

On Fri, 7 Apr 2000, Ask Bjoern Hansen wrote:

|And the other way around, there is three gazillion open proxies you can
|abuse to make requests from different ip addresses.
|
|Or a determined attacker might have a lot of different local ip addresses
|at his disposal he can make requests from.

Let's be realistic on this one: if the idea is to prevent brute force
attacks, the fact that the attacker might use a few dozens or for that
matter a few hundreds IPs won't matter much. 

Re: THREE STRIKES...

[Ask Bjoern Hansen]

On Fri, 7 Apr 2000, Mark Imbriaco wrote:

> > |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.
> > 
> > Obviously, you want to count attempts PER IP addresses. 
> 
> What about folks who are behind proxies?  (ie: AOL) It is not all that far
> fetched to consider that an attacker and a legitimate user could both be
> coming from AOL -- neiter is it farfetched to consider that they may be
> assigned the same proxy server on the AOL network.

And the other way around, there is three gazillion open proxies you can
abuse to make requests from different ip addresses.

Or a determined attacker might have a lot of different local ip addresses
at his disposal he can make requests from.
 
> There ARE workarounds to the issue, my point was simply that Vivek's
> cookie idea is probably the best of the (admittedly numerous) bunch.



 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: THREE STRIKES...

[Eric L. Brine]

Why not track IP instead of user name in failed attempts? e.g. Lock out IP
www.xxx.yyy.zzz for an hour if it makes 6 successive bad attempts?

I realize the attacker could change his IP, but that takes time.

I realize that two people can share an IP (e.g. proxy users), it opens for
the possibility of locking out a legitmiate user by an attacker (DoS) if
they are on the same proxy, but that might be acceptable. I also set the
count a bit higher ('6' instead of '3') to compensate for multiple users
trying to login from the same proxy.

Of course, adding a "sleep(5)" before returning a message saying the
attack failed would help too.

ELB

--
Eric L. Brine  |  Chicken: The egg's way of making more eggs.
[EMAIL PROTECTED]  |  Do you always hit the nail on the thumb?
ICQ# 4629314   |  An optimist thinks thorn bushes have roses.

Re: THREE STRIKES...

[Vivek Khera]

> "NM" == Nicolas MONNET <[EMAIL PROTECTED]> writes:

NM> |it's possible to work around this, but the best way is probably going to
NM> |be cookie based like Vivek suggested.

NM> Obviously, you want to count attempts PER IP addresses. 

You don't deal much with AOL or MSN proxies do ya?   Millions of
users, a handful of IPs, and they can change from one request to the
next.

Re: THREE STRIKES...

[Gunther Birznieks]

Also, some legitimate people turn off cookies. In addition, weird browsers
(especially PDAs with limited memory) tend not to implement cookies. So those
are considerations for locking out users that may be legitimate.

However, I would rather think that the cookies would be an advisory security
mechanism used in conjunction with the 3 strikes. Not something that a user has
to use in this case, but something that helps make sure some yahoo with a
browser doesn't do the DoS attack along with the 3 strikes.

Cookies are, of course, spoofable so that then becomes something that you would
have to watch out for from a serious hacker. I guess at that point it's just a
matter of tradeoffs again...

Nicolas MONNET wrote:

> Ahem, now if we have to take AOL users into account ... j/k.
>
> Actually, I don't see how cookies could be implemented; if the attacker
> rejects cookies, how are you going to do it? ...
>
> On Fri, 7 Apr 2000, Mark Imbriaco wrote:
>
> |What about folks who are behind proxies?  (ie: AOL) It is not all that far
> |fetched to consider that an attacker and a legitimate user could both be
> |coming from AOL -- neiter is it farfetched to consider that they may be
> |assigned the same proxy server on the AOL network.
> |
> |There ARE workarounds to the issue, my point was simply that Vivek's
> |cookie idea is probably the best of the (admittedly numerous) bunch.

Re: THREE STRIKES...

[Gunther Birznieks]

Mark Imbriaco wrote:

> On Fri, 7 Apr 2000, Gunther Birznieks wrote:
>
> > 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).
>
> In that case, sure it's possible.  And fairly trivial to implement at
> that.  I am not trying to start an argument of any kind, and I'm pretty
> sure that my first messages wasn't inflammatory, though it appears that
> you may have taken it that way.
>

You're right on all your other accounts. But not trying to start anything, just
wanted to emphasize the primary point of the thread so it didn't get lost. I
guess security stuff does always end up finding its way in web discussion
threads anyway. I guess there is no escaping it. And perhaps maybe there
shouldn't be. :)

Sorry,
   Gunther

Re: THREE STRIKES...

[Nicolas MONNET]

Ahem, now if we have to take AOL users into account ... j/k.

Actually, I don't see how cookies could be implemented; if the attacker
rejects cookies, how are you going to do it? ... 



On Fri, 7 Apr 2000, Mark Imbriaco wrote:

|What about folks who are behind proxies?  (ie: AOL) It is not all that far
|fetched to consider that an attacker and a legitimate user could both be
|coming from AOL -- neiter is it farfetched to consider that they may be
|assigned the same proxy server on the AOL network.
|
|There ARE workarounds to the issue, my point was simply that Vivek's
|cookie idea is probably the best of the (admittedly numerous) bunch.

Re: THREE STRIKES...

[Mark Imbriaco]

On Fri, 7 Apr 2000, Gunther Birznieks wrote:

> 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.
  
And they're not safe from DoS, so the theory is correct! :-)  I'm not
saying that it's not a tradeoff that one might want to meke, I just
thought it would be worthwile to mention that there are some drawbacks to
this approach.
 
> 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.
  
Exactly right.  It would even be possible to put in some more advanced
logic there to setup thresholds for notifying the sysadmin, and perhaps
sending the user instructions for reactivating their account without
sysadmin intervention.  The door is wide open -- again, I just wanted to
make sure that the person asking the question understood that there are
drawbacks to the approach.
 
> 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).

In that case, sure it's possible.  And fairly trivial to implement at
that.  I am not trying to start an argument of any kind, and I'm pretty
sure that my first messages wasn't inflammatory, though it appears that
you may have taken it that way.

-Mark

Re: THREE STRIKES...

[Mark Imbriaco]

On Fri, 7 Apr 2000, Nicolas MONNET wrote:

> On Fri, 7 Apr 2000, Mark Imbriaco wrote:
> 
> |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.
> 
> Obviously, you want to count attempts PER IP addresses. 
> 

What about folks who are behind proxies?  (ie: AOL) It is not all that far
fetched to consider that an attacker and a legitimate user could both be
coming from AOL -- neiter is it farfetched to consider that they may be
assigned the same proxy server on the AOL network.

There ARE workarounds to the issue, my point was simply that Vivek's
cookie idea is probably the best of the (admittedly numerous) bunch.

-Mark

Re: THREE STRIKES...

[Ken Williams]

[EMAIL PROTECTED] (Ken Williams) wrote:
>
>I should point out that if someone feels the need to use a 3-strikes system,
>then cookies are inherently a bad decision unless you get really fancy. 

And I should amend my statement to say that cookies can be a good idea in this
case (and lots of others), but are only secure when combined with server-side
data.

Re: THREE STRIKES...

[Ken Williams]

[EMAIL PROTECTED] (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.

I should point out that if someone feels the need to use a 3-strikes system,
then cookies are inherently a bad decision unless you get really fancy. 
3-strikes means you don't trust the user and you're trying to prevent attacks
where lots of passwords are tried.  And if the user isn't trusted, then you
shouldn't trust the user to send a nice little cookie back every time he/she
tries to log in.  It's quite easy to write a LWP script or whatever that tries
to log in using lots of passwords without sending cookies, or that sends bogus
cookies.

One could circumvent this by requiring a cookie (even for the first attempt),
and never sending the same cookie out of your server more than once.  Which
means you'd need some kind of counter or something, which means you're using a
database, which means you might as well just use the simple database scheme as
originally suggested.

It's also difficult to implement a lockout time with cookies, because the user
could just quit the browser & relaunch to clear cookies.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Re: THREE STRIKES...

[Nicolas MONNET]

On Fri, 7 Apr 2000, Mark Imbriaco wrote:

|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.

Obviously, you want to count attempts PER IP addresses. 

Re: THREE STRIKES...

[Gunther Birznieks]

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
>  
> 
> 

Re: THREE STRIKES...

[Mark Imbriaco]

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
 

Re: THREE STRIKES...

[Gunther Birznieks]

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.

Vivek Khera wrote:

> > "GJ" == Gram, Jim <[EMAIL PROTECTED]> writes:
>
> GJ>  This is more an Apache question, but here goes.  Is there any way to
> GJ> modify the "Authorization Required" page received after three failed
> GJ> attempts to login in using Basic Authentication (or insert a custom page) ?
> GJ> Also, can the number of attempts before failure be  modified?  Thanks in
> GJ> advance???
>
> The HTTP protocol is stateless, so you have no way to count such
> attempts.  You need to introduce state using cookies and possibly a
> database on your end.
>
> But this has nothing to do with mod_perl, as you said up front.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D.Khera Communications, Inc.
> Internet: [EMAIL PROTECTED]   Rockville, MD   +1-301-545-6996
> PGP & MIME spoken herehttp://www.kciLink.com/home/khera/

Re: THREE STRIKES...

[Vivek Khera]

> "GJ" == Gram, Jim <[EMAIL PROTECTED]> writes:

GJ>  This is more an Apache question, but here goes.  Is there any way to
GJ> modify the "Authorization Required" page received after three failed
GJ> attempts to login in using Basic Authentication (or insert a custom page) ?
GJ> Also, can the number of attempts before failure be  modified?  Thanks in
GJ> advance???

The HTTP protocol is stateless, so you have no way to count such
attempts.  You need to introduce state using cookies and possibly a
database on your end.

But this has nothing to do with mod_perl, as you said up front.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-301-545-6996
PGP & MIME spoken herehttp://www.kciLink.com/home/khera/

THREE STRIKES...

[Gram, Jim]

Dear Mod_perlers,
 This is more an Apache question, but here goes.  Is there any way to
modify the "Authorization Required" page received after three failed
attempts to login in using Basic Authentication (or insert a custom page) ?
Also, can the number of attempts before failure be  modified?  Thanks in
advance???
 
 
Regards, 
Jim Gram 
Aircraft Owners and Pilots Association 
Internet Services Division 
421 Aviation Way 
Frederick, MD  21701 
(301) 695-2382 
FAX: (301) 695-2375 
Email:  [EMAIL PROTECTED] 

 Notebook.jpg