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

[Joseph Bui]

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