Re: Re: Passing data between frames

From: Mark Reardon <riscorp(at)mindspring.com>
Date: Mon Mar 31 2003 - 17:54:27 EST

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

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

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 Received on Mon Mar 31 18:04:03 2003