Another way to do it, if you want a bit more security: Use a cookie *only* to hold an encrypted sessionid (string or number, whatever, but encrypted). This is, of course, how ASP does it already: Only the sessionid is encrypted and stored in a cookie.
Then you manage your own "session variables" in one of two ways:
(1) Use a database. Use the un-encrypted sessionid as the record identifier of the table that holds the session variables. Your table design could be as simple as
CREATE TABLE sessions (
So to store a session "variable" you would do
INSERT INTO sessions VALUES( 3371, 'username', 'bob' );
INSERT INTO sessions VALUES( 3371, 'password', 'zamboni' );
where 3371 is the unencrypted session id.
(2) The same thing, but you use application variables to hold the session info. You could keep each user's session info in a 2D array and then store the entire array in a single application variable. Thus:
sessioninfo(0,0) = "name" : sessioninfo(0,1) = "bob"
sessioninfo(1,0) = "password" : sessioninfo(1,1) = "zamboni"
application("3371") = sessioninfo
Since each users application key (their sessionid) would be different, you wouldn't even need to worry about locking.