See it always pays to read the Eagle book several times - in this case pages 213-218. 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?
Thanks for the help, --Joe Breeden --------------------------------------- If it compiles - Ship It! Aranea Texo > -----Original Message----- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 15, 2001 4:52 PM > To: Joe Breeden; mod_perl List > Subject: Re: Cookie authentication > > > > Here we insert a session id on all requests, with > Apache::Session whether > > the request is for a static or dynamic page and have a > TransHandler to > strip > > the session id and insert it into %ENV which seems to work > for us. With > this > > approach we don't necessarily need cookies, but verifying > if a user is > who > > the session was originally assigned to without a cookie is really > > impossible. At least to me with the limited amount of brain > time I have > put > > into it. Using some algorithm consisting of the end-users > IP and some > random > > number is OK until users behind the same NAT device try to > steal each > others > > session. Using the cookie is a way to verify that a user is > the owner of > the > > session id. > > Cookies are very easy to fake and modify on the client side. > If you want to > verify that a user is returning a session ID you sent him > without modifying > it you should use a MAC, like the ticket access stuff in the > Eagle book. > > - Perrin >
