It's as secure as the key shared by the login method and the object in the session data.
ie, choose it well. :-)
Yeah, although it's really the same thing in this case. Encrypting the user info with a shared key and storing it in a cookie isn't really all that much less secure that storing the user info in a session data object. Although I guess it could be argued
Yes, I see that - but I didn't think any of the existing cookie-based products even did that... I thought they just encoded a concatenation of username and password in base64 (which is trivially decodable) and stored that. Was I not looking hard enough?
Of course, I'm assuming that CST includes checks to guard against cookie-hijacking. :-)
Um... maybe. What kind of checks did you have in mind? ;-)
:-) Hmmm, let's see... OK, I've never done this myself but I remember reading that it's a good idea to do this kind of thing to your cookie values to ensure they're not hijacked: 1. Start with the data you want to store 2. Append identifying information, eg the IPs of the client and server, and the current date/time. 3. Make a digest of this plus a secret string which only you know, and append that as a fingerprint. Then when you interpret the cookie, check that the fingerprint is as you'd expect (ie the cookie hasn't been interfered with by a man in the middle) and then check anything else you want to check (eg the IP/date). Once you're happy with the fingerprint, you check that the server IP is the IP of the host box, that the client IP is good too, and that the date/time aren't unreasonably out of date - the idea is to guard against re-use of old cookies or cookies from somewhere else. As I say, I've never done this but it sounds reasonable in principle. Make sense? -Andy -- Andy Gimblett - Programmer - Frontier Internet Services Limited Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/ Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request.