To clarify

Any login system implemented in PHP or whatever language it stores in the session login data, in particular the password or the combination of password + username, is an insecure system.

Session Cookie Security

Session cookies, $_SESSION , which are generated and saved on the server can be accessed by third parties, although it requires some work, so any data to be saved in the session should be non-compromising data and in order to optimize the code and / or reduce the number of queries to the database. >

The PHP Security Consortium has an online safety guide which highlights two problems with the session, although they can be overcome with due diligence on the part of the programmer:

• Session Fixation

    

  Fixation is the simplest method of obtaining a valid session identifier. While it is not very difficult to defend against, if your session mechanism consists of nothing more than session_start() , you are vulnerable.

  that translated:

    

  Fixing is the simplest method of obtaining a valid session identifier. While it's not too difficult to argue, if your session engine consists of nothing more than session_start() / a>, you're vulnerable.

• Session Hijacking

    

  Arguably the most common session attack, session hijacking refers to all attacks that attempt to gain access to another user's session.

       

  As with session fixation, if your session mechanism only consists of session_start() , you are vulnerable, although the exploit is not as simple.

  What translated:

    

  Probably the most common attack on the session, session hijacking refers to all attacks where you attempt to gain access to another user's session.

       

  As with session fixation, if your session engine consists of only session_start() , you're vulnerable, although a successful attempt might not be as simple.

Session Limitation

The session has a limit on the stored data that is imposed by the maximum file size in the system operating. However, there is also the memory limit imposed by the directive memory_limit that limits the amount of memory a PHP script can consume on the server.

Of the two, the lower the space the session can occupy.

Session vs Database-Data

The session when created generates a unique ID per visitor, which ID allows us to identify the person differently from the others. This ID stored in a database login table along with the rest of the information we need for the user session is in fact one of the most secure ways to keep the website / application login system.

Where security is a more critical factor than it usually is, we can see things this way: In theory, it is easier to get to the data in session than to get to the data in the given database being behind more access passwords.

What to save in session

Saving data in the session as well as getting to use or not the session is something that will depend on the information to manage. As a rule, the session becomes useful for storing information of the type:

• Form Errors;
• Messages to the user;
• Addresses for redirection after a given action.

That is, the session gives us the flexibility to keep data persistently and easily accessible. The session is not properly a database for storing critical or compromising information.

Summary

Database to store logged in user data is the way forward.

Session usage is particularly useful for storing help information for navigation and interaction with the user.

Compromising data should remain in the database, never in session.

Login + Password never save in session and password never save without being encrypted.

The problem is that the cookie is on the visitor's machine and is available easily and anyone can edit it. Imagine my id is "Peter". I'm on your site with login. I'll take a look at the Cookie and see inside "id = Peter". I'll ask a colleague which one and his id, he will tell me that it is (for example) "max". I'm going to put a cookie with "id = max" and I could connect myself like it. It's not very safe ...

The difficulty is that you can not have asymmetric encryption because you will have to read the cookie to take information. Therefore, you must determine what you need to store, prepare the data as a string, encrypt the string and put it in the cookie. After reading, you will have to decipher the cookie and remove the "string" and check the integrity. You can for example encrypt according to the Cookie submission date, the location of the visitor etc ... So if someone managed to "break" the cookie, he will also need to know the geographic location of which he wants to usurp identity, which quickly becomes complicated.

Here is a small class of encryption that can help you. I obviously can not show you the full path I use to encrypt my cookies.

 class Chiffrement
{
// Cipher:
// cast-128 gost rijndael-128 twofish arcfour cast-256 loki97 rijndael-192
//  saferplus wake blowfish-compat des rijndael-256 serpent xtea blowfish
// enigma rc2 tripledes 

// Modes:
// cbc cfb ctr ecb ncfb nofb ofb stream 

private static $cipher  = MCRYPT_RIJNDAEL_256;  // Cipher

private static $mode    = 'cbc';  // Mode (blocoss)

public static function crypt($data,$key)
{
    $keyHash = md5($key);
    $key = substr($keyHash, 0,   mcrypt_get_key_size(self::$cipher, self::$mode) );
    $iv  = substr($keyHash, 0, mcrypt_get_block_size(self::$cipher, self::$mode) );

    $data = mcrypt_encrypt(self::$cipher, $key, $data, self::$mode, $iv);
    return base64_encode($data);
}

public static function decrypt($data,$key)
{
    $keyHash = md5($key);
    $key = substr($keyHash, 0,   mcrypt_get_key_size(self::$cipher, self::$mode) );
    $iv  = substr($keyHash, 0, mcrypt_get_block_size(self::$cipher, self::$mode) );

    $data = base64_decode($data);
    return mcrypt_decrypt(self::$cipher, $key, $data, self::$mode, $iv);
}
}

I will complete to answer in cometario: in the case of databases, sessions, and very difficult to know where the data is. And really, it does not matter. If a person can do a SQL injection, they do not need to know "exactly where" the data is: they need to know how to read the data. Enough. So, find that everything is right because the data not on the server is a joke: what you need and protect the lit, then avoid "giving the house key". The difficulty is that the visitor ... must have the key to access! It means the key will be in the browser.

The biggest problem is the connection between the key and the data and the main question and how to avoid copying the key, and worse, how to prevent a person from understanding the key system to make a copy equal to what It looks the same. "

Analyzing the Cookie in your browser allows you to easily see that it has to be unprotected: you will var your id for example. With software like link you can modify the cookie.

This means that you need to modify the cookie to avoid modification, rather than the Id, to create a link between the cookie data. The goal will never be to put all the info in the cookie: the goal is to prevent the modification of the cookie and have the ability, on the server side, to know that the key is stuck. Then, with a core key, reading the BDD data is easy.