What to save in a login session?

Question

I am developing a login system in PHP and Mysql for an administration panel, and I have seen many "secure" login systems where they store in the session the user login or password, that is when they are not both or even all the data of the logged in user.

I have built login systems before, and it was basically this way, but I need something more secure, I can’t save user login information to the session.

Any tips? idea?

Answer 1

To clarify

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

---

The security of session cookies

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

PHP Security Consortium has a online guide on security where it highlights two problems with the session, although they can be overcome with due care by the programmer:

• Session Fixation

  Fixation is the simplest method of obtaining a Valid Session Identifier. While it’s not very Difficult to Defend Against, if your Session Mechanism consists of Nothing more than session_start(), you are Vulnerable.

  that translated:

  Fixation is the simplest method of obtaining a valid session identifier. Although it is not very difficult to defend, if its session mechanism consists of nothing else than session_start(), you are 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 isn’t as simple.

  That translated:

  Probably the most common attack on session, session hijacking refers to all attacks where one tries to gain access to another user’s session.

  As with session setting, if your session mechanism consists only of session_start(), you are vulnerable, although the successful attempt is not so simple.

Limitation of the Session

The session has a limit with respect to stored data that is imposed by size file maximum in the operating system. However, there is also the recall 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 lowest will be the maximum space that the session can occupy.

Session vs Database

The session when created generates a unique ID per visitor, ID that allows us to identify the person differently from others. This ID stored in a login table in the database along with the other information we need for the user session is in fact one of the safest ways to maintain 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’s easier to get to the session data than to get to the data in the database because it’s behind more access passwords.

What to keep in session

Storing data in the session as well as whether or not we use the session is something that will depend on the information to manage. Usually the session becomes useful for storing information of type:

• Errors in a form;
• Messages to the user;
• Redirect addresses after certain action.

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

---

Summary

Database to store login user data is the way to go.

Session usage is particularly useful for storing information to aid navigation and user interaction.

Compromising data must remain in database, never in session.

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

Answer 2

The problem is that the cookie is in 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 Cookie and see inside "id = Peter". I’m going to ask a colleague what his id is, he’s going to tell me what it is (for example) "maximo". I will put a cookie with "id = maximum" and I could connector myself like it. It’s not very safe ...

This requires that the cookie contains enough information for you to know who is logged in (not only your id, but also other information that you can mix to check if they are correct, for example visitor id, your age, your zip code etc ...) and also that the cookie is encrypted.

The difficulty is that you cannot have an asymmetric encryption because you will have to read the cookie to carry information. Therefore, you must determine what you need to store, prepare the data as a string, encrypt the string and place 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 date of presentation of the Cookie, the location of the visitor etc ... So if someone managed to "break" the cookie, he will also need to know the geographical 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’t 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 on the comet: in the case of databases, sessaos, it is very difficult to know where the data are. And really, it doesn’t matter. If a person can make an SQL injection, they don’t need to know "exactly where" the data is: they need to know how to read the data. And enough. So, think that everything is fine because the data is not on the server and a joke: what you need and protect the lit, then, avoid "give the key to the house". The difficulty is that the visitor... must have the key to access! It means that the key will be in the browser.

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

Analyzing the Cookie in your browser allows you to easily see that it has that are not protected: vc will var your id for example. With a type software https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg?hl=fr you can modify the cookie.

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