Ndtyjky

I want to generate identifier for forgot password . I read i can do it by using timestamp with mt_rand(), but some people are saying that time stamp might not be unique every time. So i am bit of confused here. Can i do it with using time stamp with this ?

Question

What's best practice to generate random/unique tokens of custom length?

I know there are lot of questions asked around here but i am getting more confused after reading different opinion from the different people.

In PHP, use random_bytes(). Reason: your are seeking the way to get a password reminder token, and, if it is a one-time login credentials, then you actually have a data to protect (which is - whole user account)

So, the code will be as follows:

//$length = 78 etc

$token = bin2hex(random_bytes($length));

Update: previous versions of this answer was referring to uniqid() and that is incorrect if there is a matter of security and not only uniqueness. uniqid() is essentially just microtime() with some encoding. There are simple ways to get accurate predictions of the microtime() on your server. An attacker can issue a password reset request and then try through a couple of likely tokens. This is also possible if more_entropy is used, as the additional entropy is similarly weak. Thanks to @NikiC and @ScottArciszewski for pointing this out.

For more details see

• http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html

This answers the 'best random' request:

Adi's answer¹ from Security.StackExchange has a solution for this:

Make sure you have OpenSSL support, and you'll never go wrong with this one-liner

$token = bin2hex(openssl_random_pseudo_bytes(16));

_{1. Adi, Mon Nov 12 2018, Celeritas, "Generating an unguessable token for confirmation e-mails", Sep 20 '13 at 7:06, https://security.stackexchange.com/a/40314/}

The earlier version of the accepted answer (md5(uniqid(mt_rand(), true))) is insecure and only offers about 2^60 possible outputs -- well within the range of a brute force search in about a week's time for a low-budget attacker:

• 
  mt_rand() is predictable (and only adds up to 31 bits of entropy)


• 
  uniqid() only adds up to 29 bits of entropy


• 
  md5() doesn't add entropy, it just mixes it deterministically

Since a 56-bit DES key can be brute-forced in about 24 hours, and an average case would have about 59 bits of entropy, we can calculate 2^59 / 2^56 = about 8 days. Depending on how this token verification is implemented, it might be possible to practically leak timing information and infer the first N bytes of a valid reset token.

Since the question is about "best practices" and opens with...

I want to generate identifier for forgot password

...we can infer that this token has implicit security requirements. And when you add security requirements to a random number generator, the best practice is to always use a cryptographically secure pseudorandom number generator (abbreviated CSPRNG).

Using a CSPRNG

In PHP 7, you can use bin2hex(random_bytes($n)) (where $n is an integer larger than 15).

In PHP 5, you can use random_compat to expose the same API.

Alternatively, bin2hex(mcrypt_create_iv($n, MCRYPT_DEV_URANDOM)) if you have ext/mcrypt installed. Another good one-liner is bin2hex(openssl_random_pseudo_bytes($n)).

Separating the Lookup from the Validator

Pulling from my previous work on secure "remember me" cookies in PHP, the only effective way to mitigate the aforementioned timing leak (typically introduced by the database query) is to separate the lookup from the validation.

If your table looks like this (MySQL)...

CREATE TABLE account_recovery (

    id INTEGER(11) UNSIGNED NOT NULL AUTO_INCREMENT 

    userid INTEGER(11) UNSIGNED NOT NULL,

    token CHAR(64),

    expires DATETIME,

    PRIMARY KEY(id)

);

... you need to add one more column, selector, like so:

CREATE TABLE account_recovery (

    id INTEGER(11) UNSIGNED NOT NULL AUTO_INCREMENT 

    userid INTEGER(11) UNSIGNED NOT NULL,

    selector CHAR(16),

    token CHAR(64),

    expires DATETIME,

    PRIMARY KEY(id),

    KEY(selector)

);

Use a CSPRNG When a password reset token is issued, send both values to the user, store the selector and a SHA-256 hash of the random token in the database. Use the selector to grab the hash and User ID, calculate the SHA-256 hash of the token the user provides with the one stored in the database using hash_equals().

Example Code

Generating a reset token in PHP 7 (or 5.6 with random_compat) with PDO:

$selector = bin2hex(random_bytes(8));

$token = random_bytes(32);



$urlToEmail = 'http://example.com/reset.php?'.http_build_query([

    'selector' => $selector,

    'validator' => bin2hex($token)

]);



$expires = new DateTime('NOW');

$expires->add(new DateInterval('PT01H')); // 1 hour



$stmt = $pdo->prepare("INSERT INTO account_recovery (userid, selector, token, expires) VALUES (:userid, :selector, :token, :expires);");

$stmt->execute([

    'userid' => $userId, // define this elsewhere!

    'selector' => $selector,

    'token' => hash('sha256', $token),

    'expires' => $expires->format('Y-m-dTH:i:s')

]);

Verifying the user-provided reset token:

$stmt = $pdo->prepare("SELECT * FROM account_recovery WHERE selector = ? AND expires >= NOW()");

$stmt->execute([$selector]);

$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

if (!empty($results)) {

    $calc = hash('sha256', hex2bin($validator));

    if (hash_equals($calc, $results[0]['token'])) {

        // The reset token is valid. Authenticate the user.

    }

    // Remove the token from the DB regardless of success or failure.

}

These code snippets are not complete solutions (I eschewed the input validation and framework integrations), but they should serve as an example of what to do.