Digital ID Coding

Reading the Session article somehow - are they always needed? I remembered my long-standing torment for the same reason.
Once I also built hashes from the received and server data in order not to show the internal identifier to the user, and I kept the signature of the latter in the database.

However, over time, I stopped arranging such an algorithm, and I wanted to reduce the number of containers in cookies to a minimum.
Do not seek it, if you already had it (I looked for it - I didn’t find it in Habré), and also if someone doesn’t like it, and not for the sake of pride, but for the benefit of:

(the algorithm for encoding / decoding the identifier fits into one line, but for readability it is separated in stages)

  <? php
 $ user_id = 1;
 $ crc32 = crc32 ($ _ SERVER ['REMOTE_ADDR']. '-'. $ _SERVER ['HTTP_USER_AGENT']);

 // encode the id
 $ cookie = $ user_id + abs ($ crc32);
 $ cookie = decbin ($ cookie);
 $ cookie = str_pad ($ cookie, 32, '0', TR_PAD_LEFT);
 $ cookie = strrev ($ cookie);

 // decode the identifier
 $ user_id = strrev ($ cookie);
 $ user_id = bindec ($ server);
 $ user_id - = abs ($ crc32);
 ?> 

(For function descriptions, see the documentation .)

What do we get? And we get a binary string of 32 characters, which is encoded and decoded on the fly (the above code on my machine took 0.00007 seconds).
The algorithm can be somehow simplified or complicated, but in any case - if it is not known to anyone who wants to decode it, then it will simply fail.
The algorithm of the given example is actually very simple and there is a chance that the attacker will calculate it, but by changing it a little, you can get any unpredictable sequence in the $ cookie container that you can only convert back.
For example, instead of turning the entire string ( $cookie = strrev($cookie); ), build the following:

  <? php
 $ chr_num = (int) $ _ SERVER ['REMOTE_ADDR']% 30;
 $ str_rev = strrev (substr ($ cookie, 0, $ chr_num));
 $ cookie = $ str_rev.  substr ($ cookie, $ chr_num);
 ?> 

and your algorithm becomes dynamic! Everything depends only on your imagination (for example, depending on the user's browser - you can turn the beginning or the end of the line, or even the middle).
')
Of the benefits:
- when returning to the server with a string, such transformations are performed so that you can safely use it in a SQL query;
- if you do not disclose the algorithm yourself - it is almost impossible to guess;
- both the identifier and his signature are hidden inside one line;
- you can be sure that the identifier does not repeat anywhere (in the original example);
- at least from 0 to 100,000,000, the string will not exceed (again, according to the initial example) 32 characters (I did not check further :)
- there is no binding to a specific computer, because everything is checked by $user_id , and the rest applies only to this computer.

Of the minuses:
- the above dynamic algorithm is not acceptable - numerical matches are possible, these lines are given only for reference (it is not difficult to find ways to solve this problem);
- theoretically it is possible by a simple search from 0 to 11111111111111111111111111111111 to get into any of the accounts, but this can be solved (he who seeks will always find);
- something else? I will be glad to hear opinions and arguments in one direction or another.

On this topic:
- CRC32 ;
- Sessions - are they always needed? ;
- PHP Documentation .