Re: Re: Passing data between frames

[Mark Reardon <riscorp () mindspring com>]

-------Original Message-------
From: Bear Giles <bgiles () coyotesong com>
Sent: 03/28/03 07:25 PM
To: Mark Reardon <riscorp () mindspring com>
Subject: Re: Passing data between frames

> Mark Reardon wrote:
> I use large handles (512 bit or larger) and I encrypt them
> using  a hash of the browser ID and high byte of the source IP
> address. I then place the handle in a cookie. I then add it to 
>  a table, and place the table index into a cookie. The table
>  also has either the information being passed or a pointer to it.

That sounds unnecessarily complex.  Why bother with the 
encryption/decryption cycle?

Hash the browser ID, source IP and some salt.  Put the hash into 
cookie.  The same cookie goes into the database with whatever
information you're tracking, using the hash as your primary key.

When you receive a cookie, recompute the hash from the same values 
and compare.  If they match, retrieve the values from the 
database.  If they don't, you could probably still flush the table 
entry based on the browser ID and source IP, although that may not 
be sufficiently unique.

> To narrow that window, table entries are
> timed (short) and only available once.

Is the uniqueness really required?

If so, you can still easily do this with just hashes.  Use the 
same approach to handle salt values in password files - just 
prepend the sequence number to the hash before encoding it in hex 
or base64 for your cookie.  When you get a cookie, pull the salt 
value and use it to generate the new hash.  The table could/should 
also contain the current sequence number.

My reply:

The point of uniqueness is to thwart people that steal cookies. Using a simple hash of the browser ID, the IP address 
upper byte (can't use the whole IP was learned from experience) and a salt would give the same value each time. If a 
cookie is stolen, the attacker can use it to appear as the real user.

You could add the sequence number (causing the hash to continually change) but that is not what I did. My team was 
attempting to satisfy some picky auditors and what I documented is what we did. I would also be concerned about attacks 
from people that know the algorithm.

By using a random number and encrypting it, any hacker that knows the algorithm is still on the outside looking in. 
Using a predicatble value and algorithm allows an attacker to create cookies ahead of the attack. A hard crack of an 
encrypted random number makes the cracking of the encryption meaningless and no before attack work is going to help.

The attack method has to be to steal a cookie and use it before the attacked browser uses it. If the attacker is late, 
they do cause a person to be logged out (denial of service). If the regular user goes to the next screen after the 
attacker, then the attacker and user are logged out. So, the critical components of the security are:

- forcing the regular user to stay active by having a short inactivity timeout,
- having a unique cookie for each screen that is near impossible to predict, even if the algorithm is known, and
- forcing a second confirmation screen for all critical actions (which causes a new cookie creation and confirmation).

Mark


----
Mark Reardon
Reardon Information Security Corporation
156 Blue Sky Drive
Marietta, GA 30068
(770) 565-0544
(404) 444-0041 cell