Techniques to auto-login using a persistent cookie.

[craigkenisston]

I have an asp.net application in which I sometimes store a persistent
cookie once the user has logged in and this has been working great.
However, I now add some user information like, username, firstname,
lastname, etc. in the session collection and this works fine, but only
the first time the user loggin.
But, when the user returns I just get nil errors, because this data is
lost.
So, I guess, I'm missing something like auto-logging the user in the
system to grab this user info from the database again, but I have no
idea how to do this, or what do I need to do, for example, should I
then store the user password in the cookie as well ?

 

[Kevin Frey]

Well you could store anything you like in a cookie, but I don't think
storing a password in the user's cookie would be a good idea.

Instead I would be storing some kind of randomly generated identifier in the
cookie and using this to lookup the required information from a persistent
store (eg. a database, a file etc).

 

[Tasos Vogiatzoglou]

After authenticating the user you can store an encrypted string with
username and password with one of the symmetric algorithm
implementations available in System.Security.Cryptography

As an extra thing you could get a hash of the encrypted string (plus a
salt value) to make sure that no one tampered with your cookie.

I think this is a quite secure way to achieve the functionality you
want

 

[craigkenisston]

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 ?

 

[Kevin Frey]

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