Not that I am aware of, it seems you would be better off using SSL, if you are concerned about someone hijacking the sessions you could generate your own session id (I generate random 80 character session ids instead of 32) and also limit the life of the session, you could write logic to change the session ID every n minutes which would make brute forcing the session id even harder.
Jason On Wed, 2003-02-26 at 11:34, Dennis Gearon wrote: > Is there anyway for a page to save information on a user's computer which is > accessible via java or > javascript, but doesn't get sent with each HTML request the way a cookie is? > > I had this idea, patterned after kerberos: > > 1/ A user logs into a site via a secure link. > 2/ A hash salt is stored on their computer and an > initial hash is generated for the user as a Password > to their session key. > 3/ The user is redirected to the non secure part of the site > and they have both the hash-pw plus session key in their document. > 4/ Each time they access a page on our site, a javascript fires > which generates the next sequence in the hash-pw. > 5/ the server also generates the same new sequence and compares > it. If the session key and the new password agree, then > it is the user attached to the session. > > So, this salt needs to NOT be transmitted via the cookie so > that it does not appear 'in the clear', which would invalidate > it's use. > > Please CC me when you reply to the list, I am on digest. > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
