I just read on the Microsoft site that the sessionid may not be random, =
or even if it is, it's predictably random.  This is from =
http://msdn.microsoft.com/workshop/server/asp/aspover.asp :=20
------
The Session object is used to store information about the current user's =
Web-server session. Variables stored with this object exist as long as =
the user's session is active, even if more than one application is used. =
This object supports one method, Abandon, which (believe it or not!) =
abandons the current Web-server session, destroying any objects, and =
supports two properties, SessionID, containing the identifier for the =
current session, and Timeout, specifying a time-out value for the =
session. One thing to bear in mind about the session identifier: It's =
not a GUID [Brian:  Globally Unique ID...Microsoft's standard method of =
creating a very large non-repeating identification, used in their =
database replication procedures, and such.  The result space is so large =
that there are more identifiers than particles in the universe.  It uses =
the time and the network interface card's unique number, among other =
things, to generate the next number]. It's only good as long as the =
current Web-server session is running. If you shut down the Web-server =
service, the identifiers will start all over again. So don't use it to =
create logon IDs, or you'll have a bunch of duplicates and one heck of a =
headache.=20
------
Back to Brian:  This indicates to me that the web-server is either not =
creating random numbers, or it is following its pseudo-random sequence =
from the same starting point every time.  Of course, the only problem I =
see with that is if you are rapidly restarting the server, allowing =
multiple people to get new sessionid's from the same short list.  If =
your server runs longer than your Timeout value, however, then you =
should be fine.

But, as the author of the Microsoft document said, don't use them as =
logins...they should only be used to identify a person for a short time: =
 it's a session id, not a person id.  If you need more static =
identification, you can use a cookie.

Oh, and some advice:  I *never* put any information that the person gave =
me into their cookies.  I give them a random character string (yes, I =
make sure it's unique...it makes it less random, but more useful!), =
which references the information on my server.  I figure that I'm only =
courting danger if someone gives me personal identification and then =
they broadcast that on the Internet every time they visit me.  I'd =
prefer they broadcast otherwise nonsensical data which only I can =
understand.  This way, I can assure my customers that there is no danger =
of compromise merely because of the cookie.  I don't say it, but even =
the most paranoid (like those who think the government is spying on =
them, or that thieves will steal their computer) are secure because not =
even their own computers can compromise them.

The fact that I don't use sessionid's for any reason should not dissuade =
anyone.  I'm a Perl programmer, so it's easier for me to generate my own =
numbers.  It's not a general solution (since some people have cookies =
turned off), but I have the luxury, much of the time, to deny service to =
non-cookie users.  I know that's not normal, but I don't ever seem to =
get normal customers.  :)

Brian

• Web Designer Courses
• Off the Shelf Training Courses

HWG hwg-techniques mailing list archives, maintained by Webmasters @ IWA