471,082 Members | 733 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,082 software developers and data experts.

Best way to secure cookie session

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?
Jul 21 '05 #1
4 1408
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
Jul 21 '05 #2
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*****@yomama-nospam.com> wrote in message
news:tJ********************@adelphia.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?


Jul 21 '05 #3
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uT**************@TK2MSFTNGP14.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. :)
Jul 21 '05 #4
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*****@yomama-nospam.com> wrote in message
news:3_********************@adelphia.com...
"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:uT**************@TK2MSFTNGP14.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. :)

Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Peter Young | last post: by
5 posts views Thread by VB Programmer | last post: by
5 posts views Thread by ┼×enol Akbulak | last post: by
4 posts views Thread by Shabam | last post: by
reply views Thread by Beau Peep | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.