Why srand(time()) is a bad seed?

Question

Using srand(time()) to generate a token for a password reset (or for a CSRF token) is bad because the token can be predictable.

I read these:

• Is using microtime() to generate password-reset tokens bad practice

• REST Web Service authentication token implementation

But I don't understand how the token can be predictable. I understand that if in one second I reset my password many times I get the same token. I have the following code:

<?php

srand(time());
$reset_password_token = rand(444444444444,999999999999);

?>

If I reset my password many times in one seconds, I know I get the same token but how can an attacker exploit this?

Answer 1

It limits the scope of their brute force. For instance they only need to attempt only 60 passwords if they know someone did a reset within the last minute.

But it's worse than that. The attacker can get into any account they want by initiating a password reset for that account. After this, they generate a few tokens by repeatedly calling srand with the unix timestamp for the some small window of time around the reset, incrementing each time. One of those tokens must match unless your clock is way off.

Answer 2

Good Solutions

This assumes a 256-bit nonce is required.

1. random_bytes(32) (PHP 7.0.0+)
2. openssl_random_pseudo_bytes(32)
3. mcrypt_create_iv(32, MCRYPT_DEV_URANDOM)
4. Reading from /dev/urandom

Code snippet for #4:

<?php
function getRandom($bytes)
{
    // Read only, binary safe mode:
    $fp = fopen('/dev/urandom', 'rb');

    // If we cannot open a handle, we should abort the script
    if ($fp === false) {
        die("File descriptor exhaustion!");
    }
    // Do not buffer (and waste entropy)
    stream_set_read_buffer($fp, 0);

    $entropy = fread($fp, $bytes);
    fclose($fp);
    return $entropy;
}

Bad Solutions

• mt_rand()
• rand()
• uniqid()
• microtime(true)
• lcg_Value()

What Makes a Solution Good?

A good solution should leverage a cryptographically secure pseudorandom number generator (CSPRNG). On Unix-based operating systems, this can be achieved by reading directly from /dev/urandom.

But I don't understand how the token can be predictable.

This topic has been covered pretty in-depth before.

• Pwning RNGs (PDF)
• Predicting Random Numbers in PHP - It's Easier Than You Think
• Insufficient Entropy for Random Values

I have the following code:

<?php

srand(time());
$reset_password_token = rand(444444444444,999999999999);

?>

In theory, there would be only 555555555555 possible values for this. Unfortunately, the actual number is much lower.

rand() uses an algorithm called a Linear Congruent Generator, which because of how it's implemented in PHP 5, only works with unsigned 32-bit integers. Both of the numbers you provided are larger than 2**32. I'm not sure if it would overflow. The source code is not very enlightening in this case.

However, because you are seeding your random numbers with time(), you are going to run into trouble. Quickly, run this code:

<?php

srand(1431223543);
echo rand()."\n";

You should see 1083759687 in your console. Generally, the time difference between computers on the internet is pretty small. You could probably account for only a possible jitter of up to 2 seconds in every timezone, and it would only take you 120 guesses (worst case) to begin predicting random number output. Forever.

Please, for anything at all related to the security of your application, use a CSPRNG.

Answer 3

Time frame attack

The attacker can know/guess the time of your system. Of course a hacker can't know the exact second because for most servers that can differ a bit.

But say for instance your local time is:

> echo time();
1431212010

then you can make a "good guess" that the seed will be located between 1431212005 and 1431212015.

So if you can make like 10 guesses, the odds are very likely the password will be correct.

Of course the hacker still needs to know the algorithm that "generates" the password. But for most systems, that's rather straightforward and furthermore as always in security, it's better that one doesn't know that much about the system anyway. After all most hackers can make their own account and "inspect" how the password is generated and look for patterns first.

If the hacker has an account him/herself

A really convenient way to hack ones password is furthermore post two password reset requests approximately at the same moment: say you have an account X and you want to hack account Y. Within a millisecond, you can submit two requests, one for yourself and one for the victim. Next you receive your password and you can use it for both accounts. As @AlfredRossi says, you can furthermore enumerate over all accounts of the website and thus hack most accounts.

Solutions

Most systems offer a way to generate "real random" (of course it's debatable whether we talk about real random). For instance by capturing the noise at the audio channels or listen to other "noise". These values are less predictable since one can hardly guess what the measured intensity at an audio channel is a few thousand miles from his/her location.