0

Basically I have a login system with basic session functionality, and it times out on browser close. I've been getting complaints on that so I want to be able to have some click the remember tick and have their session last for say, 30 days.

NardCake
  • 130
  • 2
  • 9
  • 4
    http://php.net/manual/en/features.cookies.php – j08691 Aug 12 '12 at 02:32
  • Set a cookie a la @j08691's link (not really, though, since in most cases the cookie is generated by PHP, not set by the site). However, if a user closes the browser and the browser is set to delete all cookies, not much you can do in that situation. – Jared Farrish Aug 12 '12 at 02:34
  • possible duplicate of [PHP Loginsystem: Remember Me](http://stackoverflow.com/questions/3128985/php-loginsystem-remember-me) –  Aug 12 '12 at 02:37

2 Answers2

2

As said this can be done with cookies. There are plenty of tutorials but a good approach is necessary for security. I still remember, in Orkut, the long dead social networking site, you could just ask the user to run some script steal his cookies and viola the account is yours even if the user had logged out.

So here is a the best approach.

  • Create a cookie on user, hashing the user id with some salt, call it user token.

  • In your database store the token with user it belongs to and its expiry date.

  • Now when user visits with his cookie, just check if the hash is there in database and log the visitor in.

  • When user logs out just delete that token from database.

(More information)

Community
  • 1
  • 1
Shubham
  • 21,300
  • 18
  • 66
  • 89
  • Hmm. Possibly (although the actual session ID calculation is beside the point, beside it's complexity and rarity). This is more or less a session identifier, so I wonder why would we create a parallel session identifier when we already have one built-in to PHP. – Jared Farrish Aug 12 '12 at 03:05
  • Because essions aren't persistent cookies? – Shubham Aug 12 '12 at 03:10
  • So use the session ID and persist it in a DB table. – Jared Farrish Aug 12 '12 at 03:11
  • @JaredFarrish: Thats just another way, there are plenty of ways to generate unique id in PHP and thats the only thing we need. Not to forget PHP's `uniq_id()`? – Shubham Aug 12 '12 at 03:13
  • You can initiate a session with a custom session identifier, of which `uniqid()` is one way to create one. My point, however, is why do double duty and have "two"? So either keep the initial PHP-generated session identifier, or create one, but use one to inflate a session and reference a session. In some cases a second is needed to validate a session independently in some shared environments. Also, adding [`httpOnly`](http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php) to that cookie is a good idea. – Jared Farrish Aug 12 '12 at 15:02
-1

Set a cookie at the same time you're setting the $_SESSION['user_id'] for instance. Like this :

$token = hash('md5',$_SESSION['user_id'] . time() . 'salt');
setcookie('token', $token, time() + (3600 * 24 * 30));
setcookie('user_id', $_SESSION['user_id'], time() + (3600 * 24 * 30)); // Cookie expires in 30 days

Save $token in DB in user_id row.

Then you set the $_SESSION['user_id'] for users with cookies saved so they don't have to sign in the normal way:

if (!isset($_SESSION['user_id']) {

    if (isset($_COOKIE['user_id']) && isset($_COOKIE['token']) {

       $saved_token = SELECT token FROM users table WHERE userID = $_COOKIE['user_id'];
         if ($_COOKIE['token'] == $saved_token) { 
         $_SESSION['user_id'] = $_COOKIE['user_id'];
       } else log out
       }
}  else log out
}
}

Maybe that works better security wise?

NewInTheBusiness
  • 1,465
  • 1
  • 9
  • 14
  • 1
    Just remember to delete the cookies when users sign out – NewInTheBusiness Aug 12 '12 at 02:35
  • Maybe, *if* the server understands, trusts and inflates that to a session. – Jared Farrish Aug 12 '12 at 02:35
  • 3
    So all I have to do to impersonate a user on your site is submit a cookie with a valid user id? – Jared Farrish Aug 12 '12 at 02:37
  • And it doesn't matter; I can still impersonate one of your users rather easily. – Jared Farrish Aug 12 '12 at 02:39
  • Well, I have 4 set cookies that need to match...and you kinda need to sign in in the first place to get them. What's your issue? – NewInTheBusiness Aug 12 '12 at 02:40
  • What you're showing is bogus. I don't care what your *actual* site does (up to you), what you're showing is... *ahem*... Stupid. All due respect, of course. Think about it. – Jared Farrish Aug 12 '12 at 02:41
  • So ehm should I be using this or...? – NardCake Aug 12 '12 at 02:43
  • Ok, why don't you show how cookies should be implemented then to help us less knowledgable programmers out? – NewInTheBusiness Aug 12 '12 at 02:43
  • I'm just using the basic session_start() $_SESSION['user_id'] = $user_id – NardCake Aug 12 '12 at 02:44
  • It doesn't have anything to do with cookie per se. It has to do with verification and validation. You're showing something, more or less, all I have to do is submit a cookie to create a session on behalf of a user. One technique is to... Lengthen a session timeout on the server. – Jared Farrish Aug 12 '12 at 02:44
  • Jared thats exactly what I want to do add a session timeout on the server. – NardCake Aug 12 '12 at 02:45
  • But. Don't just create a session on behalf of a submitted cookie key value *alone*. That's just suicide. – Jared Farrish Aug 12 '12 at 02:46
  • basically what he is trying to say is all I have to do is create a cookie in my browser (extremely easy) that has a name of user_id with any id set , and I will automatically be authenticated as that user. YOu need to implement security – Kris Aug 12 '12 at 02:50
  • Can't you guys give a quick example of how to do that? – NewInTheBusiness Aug 12 '12 at 02:53
  • The only real answer I can think of is to lengthen the session timeout value. As I think I've shown, making a cookie value that leads to impersonation isn't particularly safe. – Jared Farrish Aug 12 '12 at 03:02
  • well at the very least you can store a cookie user_id, and then also create a cookie that is a hashed value of whatever, store it on server side as well as the cookie and validate that value. So a person would need to know both the user id and the encrypted value to gain access.. You could even then do an IP check to see if it matches (although obviously won't work well with someone who has dynamic ip) – Kris Aug 12 '12 at 03:19
  • Already implemented it on my site now after reading this. I have 4 stored cookies which set 4 $_SESSION variables. I hash one of the values with a timestamp + salt and store it and check against that value before setting any of the other $_SESSION variables. Does it sound like something which should keep it safer? Thanks for the help Kris. – NewInTheBusiness Aug 12 '12 at 03:27
  • I mean is it safe to supply all the variables like normal but adding an extra cookie which is hashed...storing that value and then checking that specific cookie against the stored value before setting the $_SESSION variables with the normal cookies and letting the user sign in. – NewInTheBusiness Aug 12 '12 at 03:30
  • If you validate a session based on a server-side check of a cookie value, that is appropriately discrete (consider [adding `httpOnly` as well](http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php), since the browser does not really need to interact with that cookie), then you are better off than before. Note, however, if I login, gain a session and it's validated cookie, and then modify the username in the cookie... Am I now able to access a session as that user? If you're looking up that they match, why have it on the client at all? – Jared Farrish Aug 12 '12 at 14:54
  • Also, CodeIgniter rather infamously uses cookies to store user session data. See the [OBSession plugin page](http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php) for some of the background and fixes it implements to the CI core session management. – Jared Farrish Aug 12 '12 at 14:56
  • No, the script only sets the session variables if the token cookie matches the stored token for that specific user. So changing the cookie user_id would lead to a mismatch in the token check before setting the session variables. – NewInTheBusiness Aug 13 '12 at 00:42