The standard way to create a cryptographically secure token using PHP seems to be:
$token = bin2hex(openssl_random_pseudo_bytes(16));
I understand if you're using Linux (which I always do) because this uses /dev/urandom — which is changed according all the many things that go on in the operating system —it makes it nigh impossible to predict.
My function is more like this so I can do it by char length rather than bit length (though I don't really ever use it, see below):
function token($charLength = 32) {
// Each byte produces 2 hexadecimal characters so bit length should be half the char length
$bitLength = $charLength / 2;
// Generate token
$token = bin2hex(openssl_random_pseudo_bytes($bitLength));
return $token;
}
Is it the unpredictability that makes it secure? I can't help thinking it's less secure because the output is hexadecimal and therefore is less hard to guess or brute-force than a string with the same number of chars that contains the rest of the alphabet, uppercase letters, other symbols, etc.
Is this why when people refer to tokens they refer to the bit length as opposed to char length?
Consider instead:
function randomString($length,
$alpha = true,
$alphau = true,
$numeric = true,
$specialChars = '') {
$string = $specialChars;
if($alpha === true) {
$string .= 'abcdefghijklmnopqrstuvwxyz';
}
if($alphau === true) {
$string .= 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
}
if($numeric === true) {
$string .= '0123456789';
}
$array = str_split($string);
$string = '';
for($counter = 0; $counter < $length; $counter ++) {
$string .= $array[array_rand($array)];
}
return $string;
}
In the context of web development when would you use the first function over the second for:
- Creating a random password for a password reset
- Creating a one-time use token (e.g. for a forgotten password link)
- Creating a salt for a password hash (e.g. bcrypt, sha512, PBKDF2)
- Creating a token for a “remember me” cookie token
In all instances I would use randomString() over token() so I guess I'm asking if and why I'm wrong in any of the above.
My rationale in relation to the above points:
- 12 char random password with uppercase, lower case and numbers is hard to guess; plus I freeze people out for 15 mins after 5 failed login attempts
- 64 char random string, If someone tried brute-forcing the token to reset a password the firewall would pick up on it
- Salts should be assumed to be public anyway, so long as they're different per password it makes it impossible to produce a rainbow table
- My remember me token is 128 char random string stored in a cookie and is salted and sha 512'd in the database
