Is restoring a session with cookies the right way?

Question

Correct me if I'm wrong please:

Sessions will last a finite amount of time (refreshed from the server every 15 or so minutes until the browser is closed) - more secure/short term
Cookies on the other hand can last until the browser closes or to some specific time in the future - least secure/long term

Given this, how do allow a user to close his/her computer, come back a few days later and open a site and still be logged in using cookies and still somehow being secure?

How does someone like, amazon for instance do this?

EDIT:

To be more clear, here is an example:

if (!isset($_SESSION['id'])) 
{   
    $_SESSION['id'] = $_COOKIE['id'];
    $_SESSION['email'] = $_COOKIE['email'];
}

this is obviously bad, what is a better way?

I think this question is entirely unclear. The user loses his session as soon as one of these things happens: cookie expires, server-side session expires. Why do you think this is "insecure"? — Niklas B., Jan 14 '12 at 23:15

score 2 · Answer 1 · answered Jan 15 '12 at 00:09

First of all, "session" is more of a concept rather than a concrete implementation.

For PHP I believe the default way that session data is stored on the file system and it is associated with a session id that is usually stored in a cookie (although it can also be sent via query string parameter:http://stackoverflow.com/a/455099/23822).

It's also possible to store session in a database. Doing so allows you full control over how session data is stored and when it expires so you can have sessions that last as long as you want them to. You just need to make sure the session cookie also shares the same expiration time as the data in the database.

As to your question of in a comment about "What's stopping someone from grabbing the cookie data and falsifying a login using the token?" Theoretically that can happen, but the session ID stored in the cookie should be random so it would be highly unlikely that it would be guessed (an attacker would have a much easier time guessing the user's password). In fact the same thing is already possible with any kind of session.

score 1 · Answer 2 · answered Jan 14 '12 at 23:18

Sessions expire mostly because keeping them open on the server is inefficient. You need a cookie (or some other mechanism, but cookies are usual) to associate them with a browser anyway.

Amazon handles security by having three levels of "being logged in".

Level 1: Basic functionality just works.

Level 2: You must reenter your password to access some things (e.g. order history)

Level 3: You must reenter payment information to access some things (e.g. adding a new delivery address)

score 0 · Answer 3 · answered Jan 14 '12 at 23:15

0

You store a session-based security token inside the user's cookie data, and store that same token in the user's db table. At session creation, you check if this username/token pair can login to your website according to the previously stored data, and then invalidate the token.

answered Jan 14 '12 at 23:15

Milad Naseri

4,053
1
27
39

What's stopping someone from grabbing the cookie data and falsifying a login using the token? – lewicki Jan 14 '12 at 23:27
I prefer to store the MAC address of the machine associated with the token. I actually do a SHA-512 of the concatenated string of the random token and the machine's MAC address and store THAT in the db. That way, it's like you are storing only a part of the password in the cookie, and associating the rest with the unique id of that computer.Likewise, you could incorporate other ID data that's unique to the browser/os/machine/etc. – Milad Naseri Jan 14 '12 at 23:30

score 0 · Accepted Answer · answered Jan 14 '12 at 23:41

0

For the cookies I use the method described here: http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/ and here: http://jaspan.com/improved_persistent_login_cookie_best_practice

answered Jan 14 '12 at 23:41

romainberger

4,563
2
35
51

Is restoring a session with cookies the right way?

4 Answers4