You can only trust the cookie if you can be sure that no-one could really
have created the cookie (the contents of it) by other means.
Tasos suggests putting your information into the cookie in an encrypted
form. Trusting the cookie then comes down to trusting whether you believe
the encryption key has been compromised or not.
The strength of the encryption determines the possibility that a hacker has
discovered the key and used it to create their own cookies.
Using a hash (eg. MD5, SHA) in conjunction with the encryption comes
increases the security purely by the fact that now two secrets must be
cracked in order to create "counterfeit" cookies (the encryption key and the
salt which was used when generating the hash).
The cookie technique is subject to various spoofing/reply attacks. Without
using HTTPS to deliver the cookie, any snooper seeing the HTTP traffic could
grab the cookie and they now have a valid login to your system, just by
spoofing the cookie contents. HTTPS ensures that the cookie itself is
delivered to the end-user in encrypted form, so it cannot be grabbed by a
snooper, in the same way HTTPS protects an internet banking login which
would otherwise be clear text.
Using a reference identifier (my suggestion) is also subject to spoofing,
but only for as long as the original session is registered. After that, the
cookie becomes useless because the identifier no longer has a corresponding
"real session" on the server. The window of opportunity is therefore much
smaller. The problem with reference identifiers is they must be "cleaned up"
out of your "lookup table" as they expire.
If you want good security, therefore, whichever cookie method you choose,
you need to protect the cookies whilst they are in transit, and that means
HTTPS.
Kevin
<cr************@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
The real question is: should I or should I not store the password ?
Can I trust that if I find the cookie, then the user must be taken as
logged in ?
