Best way to secure cookie session

[Shabam]

I'm developing an application and want to have the "remember me" feature, so
that users don't have to log back in again in the next visit.

The problem here is, what happens if the user's cookie is stolen? Or, what
prevents someone from figuring out the algorithm to the cookie session
string?

I've thought of using a random string (stored in the database) that's
written to the user's cookie once he's logged in. Since it's random there
won't be any encryption to break.

Then, whenever the user's password is updated, a replacement string is
generated and re-written to the database and also the user's cookie file.
This will invalidate any stolen cookie files.

What do you think of this? Is there a better way?

[Cor Ligthert]

Shabam,

Whatever you try this way, will never help you.
The Cookie is on the users computer in a binary format.
Whatever you check when you use only the format of that Cookie, it will
always that format how unreadable it is for users. When you want to make it
more difficult you better can use the GUID for identification, however when
it is copied it stays the same binary data.

http://msdn.microsoft.com/library/de...ClassTopic.asp

Therefore any password that is generated by the client or only in his head
will in my opinion be better.

Just my thought,

Cor

[Nicole Calinoiu]

For a site on which security/privacy is important, the site functionality
should not allow for client-side user identity token caching. Most users
will probably be using a browser that allows for login credential
auto-population, so they will already have some form of login facilitator
available that is under their control.

"Shabam" <ch*****@yoma ma-nospam.com> wrote in message
news:tJ******** ************@ad elphia.com...

I'm developing an application and want to have the "remember me" feature,
so
that users don't have to log back in again in the next visit.

The problem here is, what happens if the user's cookie is stolen? Or,
what
prevents someone from figuring out the algorithm to the cookie session
string?

I've thought of using a random string (stored in the database) that's
written to the user's cookie once he's logged in. Since it's random there
won't be any encryption to break.

Then, whenever the user's password is updated, a replacement string is
generated and re-written to the database and also the user's cookie file.
This will invalidate any stolen cookie files.

What do you think of this? Is there a better way?

[Shabam]

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uT******** ******@TK2MSFTN GP14.phx.gbl...

For a site on which security/privacy is important, the site functionality
should not allow for client-side user identity token caching. Most users
will probably be using a browser that allows for login credential
auto-population, so they will already have some form of login facilitator
available that is under their control.

Could you explain that in a less technical way? I'm completely lost by
"identity token caching", "credential > auto-population", and "login
facilitator". Thanks.

FYI, the application is being developed by hired programmers, not me. I
know many of the concepts, just not the details, hence I'm here. :)

[Nicole Calinoiu]

Sorry, that was meant to be generalized, not overly technical....

An "identity token" would be anything that could be used to identify a user
to the application. The identity token you had proposed using was a
randomly generated user-specific string.

"Caching" is the same as storing. For example, storing a user-specific
randomly generated string in a client-side cookie is an example of
client-side caching of an identity token.

"Credential auto-population" is the automatic completion of user name and
password text boxes by the browser application. For example, if you use IE
and haven't disabled this feature, you will be shown a dialog box asking if
you want the password to be "remembered " for future visits to the site. If
you allow this, IE will fill in the password textbox for you at subsequent
logins.

"Login facilitator" is functionality that makes login easier for the user.

Summary: For a site where user identity really matters, don't open
potential security holes just to make login easier on the user, particularly
since most users will probably be using browsers that already contain
functionality for easing the login process.

"Shabam" <ch*****@yoma ma-nospam.com> wrote in message
news:3_******** ************@ad elphia.com...

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uT******** ******@TK2MSFTN GP14.phx.gbl...

For a site on which security/privacy is important, the site functionality
should not allow for client-side user identity token caching. Most users
will probably be using a browser that allows for login credential
auto-population, so they will already have some form of login facilitator
available that is under their control.

Could you explain that in a less technical way? I'm completely lost by
"identity token caching", "credential > auto-population", and "login
facilitator". Thanks.

FYI, the application is being developed by hired programmers, not me. I
know many of the concepts, just not the details, hence I'm here. :)