I don't think that really solves Joe's proposed problem. Joe wants to ensure that the cookie is coming back from the client he sent it to. If you generate a unique ID, someone can sniff the network, grab the cookie, and send it as their own. The Eagle book does half-heartedly suggest IP address as being a way to ensure the cookie's source, but that's not reliable in these days of proxies and NAT.
The only answer, I think, is to only send the cookie over an SSL connection, so that it can not be sniffed. Remember that there is an attribute you can set on the cookie that tells the browser to only send the cookie over an SSL connection. Spend some time playing with Amazon and see how they handle cookies. They appear to have cookies that get sent over every connection which they use to personalize your web pages (not necessarily sensitive info). However, as soon as you try to purchase something or go to a sensitive area, you are asked to sign-in and sent a cookie over https. > From: "Perrin Harkins" <[EMAIL PROTECTED]> > Date: Thu, 15 Nov 2001 18:40:03 -0500 > To: "Joe Breeden" <[EMAIL PROTECTED]>, "mod_perl List" <[EMAIL PROTECTED]> > Subject: Re: Cookie authentication > >> Excuse my question if it seems dumb I'm not 100% on NAT and >> proxies, but the Eagle book says to 1 Choose a secret, 2 Select fields to > be >> user for the MAC. It also suggests to use the remote IP address as one of >> those fields. 3 Compute the MAC via a MD5 hash and store in the clients >> browser. 4 On subsequent visits recompute the MAC and verify it matches > the >> original stored MAC. How is this reliable in a situation where many >> similarly configured computers are behind a NAT/Proxy and one of the users >> try to steal someone else's session by getting their cookie/session_id > info? > > Don't use the IP address in the cookie, just generate a unique ID of your > own. I suggest using mod_unique_id. > - Perrin > >
