First off, I will read the article at the bottom as soon as I'm done here.
> IP addresses are not unique. Many people browse from behind > Network Address > Translating (NAT) firewalls as well as mega reverse proxies like AOL. Good point. AFAIK, the only sensitive information being passed is the session key in a cookie (encoded time() + IP address). There is a user_name cookie, but it only stores the user's login name to allow quicker logins and customizations. My reason for wanting to use the IP address was that it would be harder to forge a session key AND the IP address. > In general, it is not a good idea to pass user_names around in a cookie. > While it is true that most people can be identified by the computer they > appear to be using, it is not always true. Browser strings are not a great > match: even allowing for the existence of 100 different browser types and > flavors, you will soon discover many people have the same user > agent string. > Also, unless all your users use cookies, you may want to pass the session > data in the url, which means that some of that information could leak to > other sites. The session is authenticated based on (in this order, all must match): Session_ID && IP_Address && Session_Expiration && Username && BrowserString && DatabaseName. If any match fails, the user must login again (but considering the IP thing, I'll have to work around that). > The generally accepted method of handling sessions is to generate a unique > session id which you identify with the person. The session_id is then > associated the rest of the user information, usually in a > database. When/if > the user logs in, you can either change the state of the session to mark > that they have logged in, or generate a different kind of session_id. > > The session id is propagated to the user either in the url or > with cookies. > I initially do both and set a flag. The next time I see that > session_id, if > the flag is set and they returned a cookie, I switch to cookies, > otherwise I > continue to use the url method. Obviously, in either case, I > unset the flag. How do you ensure that the session_id isn't forged? What is the identifying criteria to match to, other than the session_id? > If you haven't already, read > 'Dos and Don'ts of Client Authentication on the Web' at > http://www.usenix.org/events/sec01/fu/fu_html/index.html I plan on it. Thanks, Grant M.
