-1

I have a big focus on security and I'm trying to secure my $_SESSION. I would like your advise.

  1. When a user create account I generate a random value from 11111 - 99999 in their profile in database.

  2. When a user login I create a session that contain most of user data (no password or any critical info). In that $_SESSION I also add a encrypted version of that random number that I've created on step 1 and I also create a $_COOKIE with the same encrypted number that I will use to check if the session is valid.

  3. On my application then when I receive a request, I check if the $_SESSION exist in fact it should exist but to prevent hacker to (guess or hack) other people's session id I compare the encryped value of the key from the $_COOKIE with the one inside the $_SESSION.

The main quest is, how secure is this method? I can't see any way a hacker can steal the $_SESSION id and at the same time the encrypted key.

the encryption of the key is generated by a encryption value located on server and not with simple md5 that in my point of view are easy to reproduce. since hacker cannot know the encryption value that i use for encrypting that key.

then at final when user send a request on server it look like this (I simplified the code).

if(isset($_SESSION['key'])){
   if($_SESSION['key'] == $_COOKIE['key']){
      // do stuff here
   }
   else {
     die();
   }
}
else {
   die();
}
Frank W.
  • 759
  • 2
  • 13
  • 32
Mireille28
  • 315
  • 5
  • 13
  • 2
    _“i cannot see any way on how a hacker can both steal the $_SESSION id of someone and at the same time know the encrypted key”_ – why not? You are storing both the session id and your random value in cookies – so if the attacker gets access to one, why should they not have access to the other at the same time? // Your question reads like you might be rather a novice in this area – in that case I think it would probably be best if you use the PHP session mechanism as it is, and don’t try to add on anything by yourself. – CBroe Apr 01 '16 at 08:06
  • yes of course my goal is to secure my application unfortunately i know that i cannot secure a user computer from being hacked but what i mainly want to prevent is ( session id guessing ) then even i think if you guest a session id in your browser you will need to also guest the encrypted key that correspond to that user. – Mireille28 Apr 01 '16 at 08:10
  • So instead of guessing one value, an attacker would now need to guess two. Essentially, you've just added *more entropy*, meaning an attacker would have to guess *a longer value*. You can realise this simply by generating a longer session id, it has the same effect. – deceze Apr 01 '16 at 08:12
  • i understand your point. but lets explain my self better – Mireille28 Apr 01 '16 at 08:14
  • every user have his own random number example i have 84882 then on the $_SESSION that number is encryped and will look like this DslkjeDfksjdflerkJLDFlkslkkdf then i think if you guest the session id the chance that you got the exact same encrypted key that is unique for every user are impossible. at the end that is not a longer sting to guest but 1 long string to guess and 1 another long sting that is only associated with that $_SESSION['key'] – Mireille28 Apr 01 '16 at 08:17
  • if they get session id your magic is useless –  Apr 01 '16 at 08:21
  • And if you express those two long strings concatenated, it's *one longer string*. Seriously, it only comes down to an attacker having to guess a given number of random characters. It doesn't matter in the least whether these characters come as a set of two or just one long string. Your scheme is no more secure than simply using one random session id of equal length as your "session id + encrypted random number". One long session id is **much simpler**, which is always a good thing in security. – deceze Apr 01 '16 at 08:22
  • You are aware that the session id generated by PHP is already a pretty long completely random value, which in practice is hardly guessable...?! – deceze Apr 01 '16 at 08:23
  • yes i am aware of that but since it guessable i want to make it unguessable. – Mireille28 Apr 01 '16 at 08:35
  • *Is* it practically guessable? Even if it is, again: just make it longer. – deceze Apr 01 '16 at 08:36
  • I'm voting to close this question as off-topic because it is not a specific programming problem. You might try asking on [security.se], but please read their help center first! – hichris123 Apr 04 '16 at 16:36

3 Answers3

1

Make sure you have an expiration on the cookie and also delete the cookie on logout.

Most of all, make sure the session expires. Otherwise someone can steal the cookie and continue the (still active) session from another machine at a later time.

I would also include the user-IP in the encryption and any other data that makes the session unique.

My Brain
  • 51
  • 4
0

There is no need to do this. Session validation is already handled for you by PHP. When you start a session, a cookie is being created on client side and a file on server side. Cookie contains file name on server side. Sessions lasts as long as cookie lives in browser or session is being destroyed.

Also see: How do PHP sessions work?

on my application then when i receive a request i check if the $_SESSION exist in fact it should exist but to prevent hacker to ( guess or hack ) other people session id i compare the encryped value of the key from the $_COOKIE with the one inside the $_SESSION

As for the beginning you could session_regenerate_id(true); to make harder for attacker to hijack your session id.

Some readings about session security:

questions/12233406 questions/5081025

Community
  • 1
  • 1
-1

The general idea looks good to me (I'm no expert).

Things to consider: What happens when the cookie doesn't exists?

An other method to generate the base value which you 'hash' later somehow, the most recommended is probably mcrypt_create_iv(). The interval you mentioned (11111 - 99999) is too narrow (in computing time); of if you wannt to get fancy random.org has nice APIs for random numbers (not just pseudo-random)

zedling
  • 616
  • 9
  • 27