OK... So how about the LoginMethod has the key as a property, defined when it's created (heck, even chosen at random and never visible to any user). Then the raw data from the SessionDataManager is useless, 'cos only the LoginMethod knows the key, but the LoginMethod can decode it and decide if they're logged in or not - right?
Or am I missing something - is this still insecure?
How about that (just trying to get into that - I always assumed that CookieCrumbler is rather secure, but it seems it could do better): When you log in, the login method authenticates you and then creates a token for you and sends it as a cookie. That token must be hard to guess (i.e. it should not just be the current time or so, but rather random). The more random it is, the more secure it is. From then on, until you log out or the session expires, your token logs you in. The login method just has to keep a dictionary of user/token pairs and expire these tokens as soon as they are no longer valid (you actually wouldn't even have to expire the cookie ...). If I didn't miss something, the only way of hacking left would be a man-in-the-middle attack. But that one could be done much more efficiently by catching your password at logon. To get rid of that problem, use SSL and check the server certificates. I don't see a better solution. It would be nice if one could use SSL for the login only, but how would you prevent the man-in-the-middle thing? Joachim