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

Thu Mar 24 14:07:46 EST 2005

A pretty slick little scheme I saw on a brasilian bank was as follows. 

From what I could tell it did the following. (I didn't look at the
source code and was just watching someone use the site)

When a user logged into his bank account via the website they were
redirected to a ssl "secured" server.   Then they were prompted for a
means to authenticate there account information (bank number, and
account number).  They were then brought to a page that asked them for a
password. Once that was submitted they were brought to a page that
required them to enter in a pin. Here was the cool part,  there wasn't
the full 10 key pin pad, it was 4 or 5 little boxes that allowed for 1-3
4-5 6-7 8 9-0, you then typed in the pin number that had been assigned
to you.  Every single time the values of the boxes would change, and
their placement would change as well.  So the next time the user logged
in it would be 4-6 1-2 3 9-0 7-8, and so forth.   They could have been
basing the placement and spread of the numbers on the pin pad by
computing a hash based on ip address, timestamp, browser type.  

For instance take that information and hash it
(e756dfe6dbd620d0edd5697140fa2747)  and drop the last 2 digits to create
a 30 char long string.

E756dfe6dbd620d0edd5697140fa27

Then cut the string up into portions of 6 char (one segment for each
keypad, meaning 6 characters per string now). 

E756df	e6dbd6	20d0ed	d56971	40fa27

Take that chunk of numbers hash them. and letters and add them up
(letters could have aprox value, a=1 b=2 c=3, etc, 0 would equal 10).
Then compare the values to a "framework" that decides if a value falls
in-between x-y then it will inherit the 

1st place holder = E756df = 1255ff6b5199816b7c0abbbaa36ac193
2nd place holder = e6dbd6 = a002da7baf9398f6eda9bdeca9893a8c	
3rd place holder = 20d0ed = 76b00ebe69c07c670712812cf8d5adce	
4th place holder = d56971 = 757783bc51a49035b2624d7c73763140	
5th place holder = 40fa27 = 47a4840a8594557e37a6213f122711a2

So now we have 5 values, we then sum each of these values (letters could
= their aprox placement,  or you could get jiggy wit it and crate some
custom based value system for alphas) and compare it to a "value matrix"
to decide what numbers would be displayed for what keypad, and what the
placement of those keypads would be. 

1st place holder = E756df = 1255ff6b5199816b7c0abbbaa36ac193 = 129
2nd place holder = e6dbd6 = a002da7baf9398f6eda9bdeca9893a8c = 159
3rd place holder = 20d0ed = 76b00ebe69c07c670712812cf8d5adce = 173
4th place holder = d56971 = 757783bc51a49035b2624d7c73763140 = 151
5th place holder = 40fa27 = 47a4840a8594557e37a6213f122711a2 = 143

We could then take those values and add the single numbers together to
get a sum for each value. 

1st place holder = E756df = 1255ff6b5199816b7c0abbbaa36ac193 = 129 =
(1+2+9) 12  
2nd place holder = e6dbd6 = a002da7baf9398f6eda9bdeca9893a8c = 159 =
(1+5+9) 15
3rd place holder = 20d0ed = 76b00ebe69c07c670712812cf8d5adce = 173 =
(1+7+3) 11
4th place holder = d56971 = 757783bc51a49035b2624d7c73763140 = 151 =
(1+5+1) 7
5th place holder = 40fa27 = 47a4840a8594557e37a6213f122711a2 = 143 =
(1+4+3) 8

Now since we have already gotten it down to single chars we will use the
last two places for the numbers 7 and 8.  That still leaves the first
three places open. 

X X X 7 8 (is what would be displayed at this point)

1st place holder = E756df = 1255ff6b5199816b7c0abbbaa36ac193 = 129 =
(1+2+9) 12  
2nd place holder = e6dbd6 = a002da7baf9398f6eda9bdeca9893a8c = 159 =
(1+5+9) 15
3rd place holder = 20d0ed = 76b00ebe69c07c670712812cf8d5adce = 173 =
(1+7+3) 11

So we now know that the following ranges need to be represented (since
we have allready added 7 and 8 to the "pin pad" that is displayed to the
user) 

1-6 9-0

Since the second range of numbers (9-0) contains no more then 2 numbers
we have no need to break it out into smaller ranges.  We can then assign
that range of numbers to the place holder that has the highest (or
lowest) value. (I picked highest so 9-0 will be assigned to the 2nd
place holder)

So the pin pad would now look like. 

X 9-0 X 7 8 

So now we just have to break out that last range into a range of numbers
and assign the placement for those numbers. 

Since there is 6 numbers involved and 2 places left we can figure out
with a simple division function how large the range of numbers has to
be.  (2 ranges of 3 numbers)

So we now have two ranges 1-3 4-6. 

We simply assign them the first to the place that has the highest value,
and the last one goes to what is left. 

So we now have a pin pad that looks as follows. 

1-3 9-0 4-6 7 8

Now based on the input of the user we can build a regular expression to
compare the pin(now a regular expression) that was entered via the pin
pad with the real one.  With never having to actually compare the real
pins.  As we can see if the regular expression matches the criteria of
the one in the database. 

IE

If the pin was  9821  the placeholders that should have been struck
would be.

2nd place
5th place
1st place
1st place   

Since we know the RANGE of these values and not the actual pin we have a
layer of security.  Granted its not perfect (we could make it stronger
by not allowing any single digits to be displayed, and using a 4 place
holder system, or even adding alphas to it as well) as portion of the
pin are revealed. 

Blah anyways I don't have nuff time to finish off this flight of fancy,
maybe some of you guys could throw some ideas my way on it.  Just sort
of came to me while musing how said website did their authentication.
Granted I don't think it is anywhere near as complex as what I have here
but who knows.   And as another disclaimer, I added the values for those
hashes in my heads so they are prob not accurate, and well I have spent
way to much time on this today anyways (about 45 min or so all day).
Back to client work.

Andre Ludwig, CISSP

-----Original Message-----
From: Joseph Bui [mailto:jbui at getactive.com]
Sent: Thursday, March 24, 2005 10:15 AM
To: owasp-washington at lists.sourceforge.net
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

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

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.