generate id Session/secure php cookie

Asked

Viewed 528 times

0

I am setting up a login system for my projects. So far I have understood that they are usually used Sesssions, preferably.

The article says that a good practice is to use session ids with at least 128 bits of size and 64 bits of entropy, to make id guessing difficult.

Does anyone have any hint to generate an id with these features?

It seems to me is only gives a Randon from 0 to 340.282.366.920.938.463.463.374.607.431.768.211.456(or something nearby)

I think it’s easier to work with an alphanumeric string, right? (with unns 26 digits)

2 answers

3


Do not use mt_rand, time, rand, lcg_value and neither uniquid. These resources CAN generate a unique but unpredictable number. Some become pathetic, to predict the time used just look at the clock, this is not unpredictable.


Use something that is a CSPRNG, a cryptographically secure pseudo-random generator, you have it in PHP 7:

random_bytes($Quantidade_De_Bytes);

So you can do:

$random = random_bytes(32);

$id = unpack('H*', $random)[1];
echo $id

The random_bytes is a CSPRNG, it is safe. Specifying 32 bytes is equivalent to 256 bits.


You don’t need hashing? SHA-3, BLAKE2, SHA-2, SHA-1, MD5, {put your name here}? No. Hashes are meant to be indistinguishable from a random string. Therefore, if you have a truly random string, or a secure pseudo-random, it is already equivalent to a hash.


The standard session system in PHP 7.1 already uses random_bytes, you can configure your strength using session.sid_length and session.sid_bits_per_character.

  • 1

    Recalling that the entropy and predictability of a random number generated with random_bytes() depends on of the algorithm CSPRNG implemented in the machine operating system. And if there is no one available, an exception will be launched.

  • If the operating system is unsafe... nothing implemented in it will be. It is much better to use the /dev/urandom (or equivalent) than using Mersenne Twister.

  • 1

    In theory, right?! A lot has been implemented based on OpenSSL and we come across the Heartbleed Bug and the mischief of NSA and its cryptographic backdoors, that have affected even the kernel linux.

  • No need to go that far, Openssl actually has several problems, including in PHP. If the NSA puts a backdoor, both a Kernel and a Userland will be compromised. Openssl makes a MD5 (I don’t know if it is until today) of /dev/random. If the /dev/random is maliciously weak, everything will go bad. So, even the own random_bytes() would be. But, this is the fault of the OS, not the function, which is not the case of a time() or mt_rand(), he is weak for being weak. If you don’t trust the OS, you can’t believe in anything else.

  • 1

    I’d rather trust a kernel full of bugs and backdoors than in the dice and in the haha coins.

1

It follows a code capable of generating a 512-bit identifier (128 characters based on 16 or hexadecimal), from the name of the user, the local time of the system, the process identifier and a random number:

<?php

$user = 'FULANO';
$pid = getmypid();
$now = new DateTime();
$rnd = mt_rand( 100000000, 999999999 );

$str = $now->format('Y.m.d.H.i.s.u.z.v.U').$user.$pid.$rnd;

$id_session = hash('sha512', $str );

echo $id_session;

?>
  • This hash('sha512', $str ); From $str using sha512 creates a hash, right? No matter $str the hash will always have 512 bits?

  • @Julianosilva Exactly, regardless of the size of $str the operation of hash SHA256 of this string will always return a string of 128 bytes hexadecimally.

  • The mt_rand is predictable!

  • 2

    @likeliz: Todo PRNG is predictable. What changes is the entropy of each implementation, which is what will determine whether the generator is cryptographically secure or not. Finite state machines are always predictable and the only way to have a truly random and unpredictable number is through some hardware able to take advantage of quantum uncertainty such as TRNGs

  • Indeed for the machine it will be predictable, but that’s the point. If the generator used prevents the attacker from predicting future data or retrieving past data, we can say that it is "unpredictable". A common PRNG is not concerned with quality or predictability. CSPRNG, on the other hand, I say is unpredictable, because it is also concerned with the strength of the operations used to provide well distributed bits. Ignoring the "Entropy-Attack", the device already collects hardware usage entropy (disks, network, mouse...), which is random, and Intel processors have the RDRAND.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.