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

Thu Mar 24 16:21:19 EST 2005

So what do you want?  (not trying to be rude just haven't read all the
emails in the thread yet)

You want to do auth but not have any sensitive auth information stored
in the database or server? (i.e. pin or password)?

You may want to do some research on zero knowledge systems (not the
company but the theory).

Cool paper describing it in very simplistic terms.
http://www.google.com/url?sa=U&start=7&q=http://www.dice.ucl.ac.be/crypt
o/publications/1990/alibaba.pdf&e=8092

Andre

-----Original Message-----
From: Joseph Bui [mailto:jbui at getactive.com] 
Sent: Thursday, March 24, 2005 3:43 PM
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

My second comment was that I'd prefer not to have a table of buzzers at
all. I'd like to avoid the table to prevent denial of service attacks
and to improve performance. The problem is that if there is no table,
the buzzer gets thrown away as soon as it is sent to the client. I'm
wondering if there is some way to determine if the buzzer has been used
without keeping an record of buzzers on the server. It seems impossible
to me right now.

Let's say you've passed authentication with a username and password. I
could generate a random string, put it into a table with your username
and then send you the random string as a cookie. Now, when you send me a
request, I look up that string in the database to assure myself that you
have been authenticated.

Instead of doing this, though, I can take your username concatenated
with a secret string that only I know. Then I can hash the result. I
send you a cookie with the hash value and your username. When you send
me a request, I take the username from the cookie and append my secret
string. Then I hash the value and compare it to the hash value in the
cookie. If they are the same then I'm sure you have been authenticated.

This system can't kick out people who have a valid session. But other
than that, it seems to me that it is as secure as a randomly generated
string. I can't think of a way to extend it for use before
authentication, though, because it is vulnerable to replay attacks. I
guess my question boils down to "is there any way to prevent replay
attacks without storing data on the server?"

-joe

-----Original Message-----
From: Jeff Williams [mailto:jeff.williams at owasp.org]
Sent: Thursday, March 24, 2005 12:14
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

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

Are you talking about a concurrency problem? Like two people walking up
with the same buzzer at the same time? If you delete the buzzer (see
below) when the first thread uses it, then there will be no buzzer for
subsequent requests using the same buzzer.

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

Why not just throw away buzzers when they get used for the first time?

--Jeff

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

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
_______________________________________________
OWASP-Washington mailing list
OWASP-Washington at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-washington

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
OWASP-Washington mailing list
OWASP-Washington at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-washington

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide Read honest & candid
reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op,ick
_______________________________________________
OWASP-Washington mailing list
OWASP-Washington at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-washington

-----------------------------------------------------------------

Confidentiality Notice
The content of this communication, along with any attachments, 
is covered by federal and state law governing electronic 
communications and may contain confidential and legally privileged 
information.  If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, 
distribution, use or copying of the information contained herein is 
strictly prohibited.  If you have received this communication in 
error, please immediately contact us by telephone at (301) 977-6966 
or e-mail info at fortrex.com.  Thank you.