As for as I understand, if I do not use SSL/HTTPS, cookies and session ids travel as plain text over the wire. An attacher can use packet sniffer to get his hand on these. How c
You can use something like the Secure Cookie Protocol (PDF) to encrypt the cookies prior to sending them. Instead of the session identifier, you could use the requested IP address, or some other identifier that's 100% specific to the user in general.
So, to set it up, you'd create a server key k
. Then, you'd create the cookie as follows:
keyhmac = HMAC(user name + expiration time, k)
encrypted = ENCRYPT(data, keyhmac)
hmacenc = HMAC(user name + expiration time + data + session identifier, keyhmac)
cookie = user name + expiration time + encrypted + hmacenc;
Then, you can decrypt it later by using the reverse process. The HMAC verifies that it was not tampered with outside your server (assuming that k
is really secret)...
The fact that it includes a session identifier (SSL is best, but IP can possibly serve) means that it's immune to replay attacks or hijacking attacks.
SSL would be best, but you can get a pretty good system by using an encryption scheme such as this. The absolute best would be combining this scheme with SSL, which then prevents all sorts of nasties (including MITM tampering, but not other MITM attacks)...
Short Answer: no encryption means unencrypted data.
Longer Answer: If you want to encrypt your HTML stuff (and I include cookies and session id as HTML stuff), they you must encrypt your data. You have two options: a. HTTPS or b. roll your own scheme. Option b is almost never a good idea.