I'm a beginner, and these may be very obvious for you, but I'm trying to understand if there are security issues with this example.

Today on Stack Overflow, I saw the following post: PHP Sessions Login with remember me.

The question is about creating a "Remember Me" function to extend the authenicated session for logged-in people.

The accepted answer was:

function setSession($username,$password,$cookie=null){
    // Other code for login ($_POST[]....)
    // $row is result of your sql query
    $values = array($username,$this->obscure($password),$row['id']);         
    $session = implode(",",$values);

    // check if cookie is enable for login
        setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');
    } else {
        $_SESSION["your_session_name"] = $session;

So, my question is not about how you should do this, but am I correct in the security issues I outlined below for this code example?

Using the OWASP Top 10 for reference, these are the issues I see:

Issue 1 :

First we can suppose that $session has the password and the username because the $value contains the username and password of the user. Also with this line:

setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');

The cookie has now the credentials of the user. A big mistake for me, see Issue 3 for more.

Issue 2 :

I read this OWASP article where they say that to prevent CSRF we need to generate a random ID associate to the SESSION or Cookie.

Obviously in this code there isn't a token or unique ID which is suspicious to me.

Issue 3 :

We can also imagine the site might be vulnerable to 'Cross-Site Scripting (XSS)'

In fact, if the credentials of the user are stored in a cookie we can execute a simple script and show the cookie.



I'm sure there may be other issue, but I've exposed the most obvious for me. Am I right in the issues I've identified? Did I miss any other big security issues with this code?

2 Answers 2


Storing sensitive data in a cookie is not necessarily unsafe, it depends how you configure the cookie. Te cookie needs to be configured as a secure cookie (limited to HTTPS only), HttpOnly flag should be set to avoid cross side scripting (the cookie will not be available from javascript) and the domain must be set to the correct value depending on the scope of the cookie. Using these settings it is OK to place the username in the cookie.

Regarding the other data in the cookie it is possible to create a triplet of username, series token and one time token. This triplet is stored in the database and in the cookie and can be compared in order to authenticate the user. There is an excellent article explaining this technique on Barry Jaspan's blog

If you would like an additional security measure, you can further encrypt the cookie value with a key found on the server so the details such as the username and tokens cannot be read on the browser even by the user himself. But if you have a load balanced environment you will have to make sure the encryption key is shared between all instances using your DB for example.

Regarding the specific implementation mentioned in your code example there are a few concerns:

  1. what does the obscure function do? even if its a one way has function it would be safer to just use a cryptographically secure pseudo-random number instead
  2. what is the idea of the row id parameter? it is not understood and is not random
  3. it is not clear what it means when $cookie is not 'on'. The authentication values are then stored in the session instead of in a cookie. If $cookie!='on' means that cookies are disabled, this is a bad practice, since session ID will be kept in the url.

You are right with all those issues. That implementation is not secure and could lead to identity theft.

It is even less secure than using HTTP basic authentication as those cookies are vulnerable to XSS attacks.

I could not think of any other issue apart from the ones you provided. (aren't they enough?). Well, there is the id of the entry of the user in the database in the cookie, so it could help in other attacks... As there is no info on that query, the only reason to include the row id is to search the database with it on next login, so it could be vulnerable to an SQL injection (not likely, though)

There are still too many details left out of that code (like the "obscure" function (reversible or hash?) or the implied SQL query) that the response seems a little weak. I mean, that code sets the cookie but, how does it use that cookie?

And why does it store the "obscured" password on the session cache of the server if there is no "cookie enabled"? I mean, you already have the passwords stored somewhere (database, LDAP, plain files, ...) so there is no need to store it again. That increases the risk of getting those passwords stolen, as that data would be unencrypted on a temporal directory on the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .