When the user logs in, the server stores the client's IP address in a session variable (so it's stored at the server end - the client just gets a session id). Authentication of subesequent pages is assumed only if the client's IP address matches the IP address stored in the session variable corresponding to the client's session.
Unfortunately not all users have a single IP. I know AOL users, for example, go through a cluster of proxies that all have their own IP addresses. This means that the web server can see a different IP every time the browser makes a request.
You might also have a problem with multi user machines. The users on the machine would be able to take over each others' sessions, even if they couldn't do it with outsiders.
I don't think this session ID problem is a fundamental design error, it's just a bug in certain implementations that are out there at the moment. If a server receives a session ID from a browser that doesn't exist, it shouldn't simply create it. Instead it should issue a new random session ID. This solves the problem doesn't it?
-- Pete
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
