What is the correct and safe/secure way to keep a user logged in? cookies? session? PHP && MYSQL

Question

Later I was asking how to logout correctly a user, now I seeing that using only cookies to keep a user logged in is not secure at all.

Keep the password in a cookie

Answer 1

Best practice is to use PHP sessions.

A PHP session is maintained by having the browser return a cryptographically secure (that is, not guessable as to the next valid value) string known as the session ID each time it makes a request during that session. The best and safest way to do that is to give the browser a session cookie, which it will then send with each request.

The alternative method to using a session cookie is to included the PHP Session ID in the request URL itself as a GET variable. An example URL might look something like:

https://www.example.com/mypage.php?PHPSESSID=cteekbf64igp5vdjjkktvoeb97

This is not as secure as using a cookie, because the URL might accidentally get shared or stolen via other means.

Security is many layered, like an onion (as the common example goes). The more secure you make something, the more effort it takes to make it secure, and the less convenient it is to use. It's a cost-benefit trade off. So you have to ask, how important is your data, is your user's privacy and safety, etc.

For me, a base level would be to use PHP sessions with the session ID forced to be in cookies (block users who disable cookies), SSL encryption all the time, on both data and the cookies, and make sure the various PHP settings which affect security for sessions are set to the best, most secure settings. You'll want to read everything on these pages and child pages:

• http://php.net/manual/en/intro.session.php
• http://php.net/manual/en/session.security.php

Answer 2

I would use a session.

To help a little on security, once a users credentials have been verified use session_regenerate_id - since the session id is what is passed across in a cookie this is important if someone is sniffing around while login in processed.

DO NOT STORE any information in the session pertaining to access credentials - a userId is often sufficient; personally I build a user object which I store in the session (these get auto serialized/unserialized between request - but you can read on that independantly).

IF you wish to set a cookie so the user doesn't have to login on the next visit perhaps store the userId and an autogenerated token which can be checked against in the database (or similar) - I would add extras to the checking too - like storing the last ipaddress with the token to check as well, if they don't match then ask for login once more.

There are quite a few approaches that can be taken - I don't offer all/'the best' - get your code reviewed by people in a php community - you learn more that way.

Answer 3

First, let me tell you this. Nothing is 100% secure. Nothing is air tight, and nothing is sacred. If motivated enough, an attacker will break every server-side defense you may put (unless you are using HTTPS, which is a different story).

You may use cookies, but cookies are highly exposed and easily modified. Never store private data, or access levels in a cookie. As it is easily stolen/modified by an attacker.

Sessions are not 100% safe either. The session ID, which the server uses to identify the client, is sent by one of 2 ways. a $_GET variable (bad), or a cookie (better, but still pretty bad). Meaning, if you are logged in as the administrator, over an unsecured WiFi, a skilled attacker (and by skilled I mean a pr0 haxx0r that downloaded a simple HTTP sniffer) can easily steal your SESSION ID. And while not getting your password, the server will wrongly identify the attacker as you, and grant him any access you may have/had.

So what to do? Sessions are on most cases safe. Advise your users to not log in under an unsecured network (buses, internet cafes, etc.). If you want to allow your user authorization to persist over time, a cookie is required. I usually use a 2 cookie system if I need that:

userid=12345
hash=password_hash($userid . $hashed_password, PASSWORD_DEFAULT)

Then I have something to match against, and the user's details weren't revealed.

---

But like I said, in the end of the day, if you really REALLY wanted to secure your users, in above to everything else written in this answer, get yourself HTTPS.

Answer 4

If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie. The trouble is that a user can block cookies or delete them at any time. If, for example, your website's shopping cart utilized cookies, and a person had their browser set to block them, then they could not shop at your website.

When you store data in cookies, you must be absolutely certain that users can’t tamper with the data in any way. There’s no way to keep users from altering the data in a cookie; it’s absurdly easy. So, in order to ensure that your website doesn’t accept cookies containing altered data, you need to either encrypt the cookie values or sign them with a hash that allows you to verify their integrity.

Answer 5

As @Madara said nothing is 100% secure and correct but as developer point of view I would say each and every methods of retaining user's session data has its own advantages and disadvantages for instance.

User Data in Cookies vs Session

If you are keeps user's session data in cookies it will consume less server's RAM memory and processing because you don't have to keep logged user's info into RAM. also if user increases then its recommended to keep user session data in cookies rather than session because keeping in session would consume server resources and your application could be slower and non responsive sometime. where as if you are keeps user's logged in data into session It would be secure than cookies but it would consume more server resources.

On final note: Both the ways are correct in its own implementation also if your application is using HTTPS protocol then security shouldn't be a concern. so I would suggest use methods of retaining user's session data according to the application's and business model's requirement.