Cookies and sessions

Question

I would like to know the proper way to create and destroy session's / cookies.

I use the following:

To create a session / cookie value:

session_start();
$_SESSION['SMUsername'] = $Username;

setcookie("SMUsername",$Username, time()+86400, "/","www.Domain.com","False","True");

To destroy a session / cookie value:

session_destroy();

if(isset($_COOKIE['SMUsername'])){
    setcookie("SMUsername","", -1, '/');    
}

Is this a good way, or is this 'not done'?

Furthermore, I have read in the following topic: Remove a cookie

It says to never store a cookie with username and/or password information. How else can you use a functionality like remember me, without a cookie?

I use the cookie to remember the user when a new browser is openend. (encrypted though, with md5) When re-opening the website, with another tab, I use a session to remember the user. Is this okay?

Guess this question has been answered already before: http://stackoverflow.com/questions/1226040/is-this-a-proper-way-to-destroy-all-sessions-in-php — Erik van de Ven, Oct 20 '14 at 13:38
That is only about sessions, not about cookies. Neither does it give an answer whether cookies is a good medium for a remember me functionality. — Revils, Oct 20 '14 at 13:39
SESSION uses cookies (usually called PHPSESSSIONID) to identify the correct session data - no need to write cookies yourself. Just use SESSION — Steve, Oct 20 '14 at 13:40
@Sliver2009 it's currently the only medium that makes sense. Although you can make something with localStorage and JavaScript, but it's silly when cookies already have all the functionality you need for that. — Madara's Ghost, Oct 20 '14 at 13:40
@Steve That doesn't help you with "remember me" functionality. — Madara's Ghost, Oct 20 '14 at 13:40
You mean I should only use cookies? Since cookies survive a browser close and a session is destroyed after a browser close. (@Steve session does not use a cookie as in remember when browser closes) — Revils, Oct 20 '14 at 13:41
If you check PHP.net, they give a proper way to delete a cookie, just set the time to history: http://uk3.php.net/manual/en/function.setcookie.php. And it's better to store the username and password information inside the database with a hash column. Than you save the hash inside your cookie and with that information you can get the username and password out of the database. — Erik van de Ven, Oct 20 '14 at 13:42
@SecondRikudo: The reason I use session AND cookies is that when the user does not check the remember me, it will keep him logged in if he does not close his browser, but goes to another tab. — Revils, Oct 20 '14 at 13:43
@Sliver2009 Session will retain while the user's browser remains open/while not very long has passed since the user's last interaction (i.e. page load). Sessions use short expiring cookies. Cookies generally can be configured with an expiry date, so they make more sense for "remember me for the next month" kinds of functionalities. — Madara's Ghost, Oct 20 '14 at 13:44
@ErikVandeVen If you read my question good, you see that the information is encrypted already in the cookies with md5 — Revils, Oct 20 '14 at 13:44
@Steve Sessions expire when the user closes their browser, or when more than X minutes pass. So no, you can't use sessions to remember a user for months, unless the user continuously uses your application for a month. — Madara's Ghost, Oct 20 '14 at 13:45
@SecondRikudo thank you for the answer In short, Use session only when you want to maintain the information when the current browser is open. Use cookies when you want to remember when new browser is opened. Use encrypted information in cookies/sessions. — Revils, Oct 20 '14 at 13:46
You can set the expiry time of a php session cookie you know: http://stackoverflow.com/questions/16108621/php-sessions-expiry-time-keeping-session-alive-for-a-specific-number-of-minute — Steve, Oct 20 '14 at 13:46
A note, MD5 is ***not*** an encryption. It's a hashing algorithm, and a bad one at that. Consider using bcrypt or even PHP's `password_hash()` for this. — Madara's Ghost, Oct 20 '14 at 13:47
@Steve you are missing the point entirely. A **session** is supposed to last until the end of the current **session**, "session" being the current interaction period the user and the application has. The user leaves, the session ends. That's the point of a session. Setting the session expiry to a month is abusing sessions. — Madara's Ghost, Oct 20 '14 at 13:48
@Sliver2009. I've read your question, but by encrypting the username and password and saving it inside a cookie, you can never guess who's the user, cause you cannot decrypt it. And there is no good reason for it to save that information inside a cookie.... That's why it's a good practice to save the hash inside the database AND cookie and search for it inside the database, so you get the right username and password. — Erik van de Ven, Oct 20 '14 at 13:49
@ErikVandeVen yes but 'hashing' the password and comparing it with a hashed password in the database is what I ment. — Revils, Oct 20 '14 at 13:50
@SecondRikudo Why is MD5 not good, I thought it was not reversible yet. — Revils, Oct 20 '14 at 13:51
@Silver2009, yes that works, except if you need the user's information... If two people have the same password, you're screwed. — Erik van de Ven, Oct 20 '14 at 13:52
@Sliver2009 [let's continue this discussion in chat](https://chat.stackoverflow.com/rooms/11/php) — Madara's Ghost, Oct 20 '14 at 13:52
@ErikVandeVen of course not, you are comparing both the username And the password hashed in the database.. since the username has to be unique, it is no problem. — Revils, Oct 21 '14 at 07:36

score 2 · Accepted Answer · answered Oct 20 '14 at 13:42

Your session/cookie destroying code is fine.

As for how to do the remember me, it's beyond the scope of this answer. However, check out this description of how to do it.

In short, you save a hash of the username and some other random string, and save it in the database, then compare when the user presents it.

Cookies and sessions

1 Answers1