[OWASP-Washington] RE: Good paper on a topic we touched on last night

[Joseph Bui]

Yes, that's it.

When implementing this scheme, the buzzer must be marked as used before
any other processing to ensure that the first thread to receive the
buzzer blocks all other threads. It might good for application
performance to tell the session storage module to throw an exception if
the update is blocked rather than waiting to obtain the lock.

Now I'm trying to figure out if there is any way to avoid using the
database to indicate that the buzzer is used. If I do not mark each
buzzer as used on the server, I am open to a replay attack. The attacker
gets one buzzer, waits for the timeout and can then send an unlimited
number of requests using the same buzzer.

-joe

-----Original Message-----
From: Jeff Williams [mailto:jeff.williams at owasp.org] 
Sent: Thursday, March 24, 2005 10:52
To: owasp-washington at lists.sourceforge.net
Cc: Arshan Dabirsiaghi
Subject: Re: [OWASP-Washington] RE: Good paper on a topic we touched on
last night

Joseph,

I think your policy is reasonable. Essentially it's like getting a table
at 
a restaurant -- you can't be seated until your buzzer goes off.  I
attached 
a J2EE filter I wrote that does a slightly different type of DOS
filtering. 
It limits the requests to a certain number per time slot (say 5 in 10 
seconds).  It has the problem (discussed in the paper) that it only
works 
for a particular session. But your solution is interesting in that it 
doesn't rely on sessions.  If there's interest, the filter could be
easily 
modified to do what you're requesting here.

// put filter on login page and login page handler
Filter pseudocode
{
  // keep a table of "buzzer" cookies with times
  if no buzzer cookie, set buzzer and redirect to login page
  else if buzzer timer not expired, set buzzer and redirect to login
page
  dochain
  if response from login page is an error, set bigger buzzer
}

Did I get this right?

--Jeff

----- Original Message ----- 
From: "Joseph Bui" <jbui at getactive.com>
To: <owasp-washington at lists.sourceforge.net>
Sent: Thursday, March 24, 2005 10:14 AM
Subject: [OWASP-Washington] RE: Good paper on a topic we touched on last

night


I like the ideas in this paper.

http://www.nextgenss.com/papers/NISR-AntiBruteForceResourceMetering.pdf

I do not understand how increasing the computation time can be used
against sophisticated attackers. All the bullet points on page 6 still
apply to this scheme. Web applications can not tell for sure where an
attack is coming from because of proxies and distributed attacks. I
suppose "defense in depth" indicates that we should increase the
computation time when we know the attempt came from the same host.

I like the idea of trusted IPs getting a shorter computation and
suspicious IPs getting a longer computation. This could be combined with
some automated adaptive changes to the lists.

I wonder why it is necessary to actually perform the calculation. What
about this:

1) User enters URL of login page
2) Client requests login form
3) Server generates cookie and establishes a timeout for this cookie
(e.g. current time + 5 seconds)
4) Server sends login form with cookie to client
5) Client interprets javascript sent with login form
6) Client starts a timer waiting for the timeout period (e.g. 5 seconds)
7) Client presents login form to user
8) User enters credentials and clicks submit
9) Client waits until timeout period expires, then submits login form
10) Server checks cookie of submission
11) If cookie is not found, go to step 3
12) If cookie timeout has not elapsed, go to step 3
13) If cookie timeout has elapsed, check credentials and continue with
login procedure
14) If credentials are incorrect, increase timeout and return to step 3
15) If credentials are correct, revoke the current cookie and create a
new authenticated cookie

This scheme seems much more fair to slower computers. Attackers probably
have fast computers, while legitimate users often have the slowest
computers. Humans tend to take a few seconds to enter their credentials
and so may not even notice the timeout because it begins as soon as the
form is received rather than when the submit button is pressed.

--
Joseph Bui     | Senior Developer   | GetActive Software
V 202-659-2838 | jbui at getactive.com | 1900 L Street NW Suite 400
F 202-659-7733 | www.getactive.com  | Washington, DC 20036

Notice: This message is confidential and for the sole use of the
intended recipient(s).


-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon
2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content. 
Register
by 3/29 & save $300 http://ads.osdn.com/?ad_idh83&alloc_id149&op=ick
_______________________________________________
OWASP-Washington mailing list
OWASP-Washington at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-washington