这种创建“真正”随机字符串的方式有意义吗？答案

【问题标题】：Is this way of creating "truly" random string makes sense?这种创建“真正”随机字符串的方式有意义吗？
【发布时间】：2018-05-07 19:40:31
【问题描述】：

一天中的美好时光，
最近，我一直在玩 Laravel Echo，并得出结论，对于任何涉及敏感信息的操作，我都需要一个令牌，它足够安全，可以用作广播频道。

所以我生成“真正”随机的想法，但基于一些数据令牌如下：

创建 127 个字符的随机字符串
使用 SHA-512 散列用户名
使用 SHA-512 散列电子邮件
使用 SHA-512 散列名字
使用 SHA-512 哈希姓氏
使用 SHA-512 散列当前时间戳
组合散列字符串并再次使用 SHA-512 散列它们
组合随机字符串（127 个字符）和散列的 5 个字符串（128 个字符）

所以我最终得到的是 255 个字符的字符串。这个令牌在每次登录时都会重新生成，所以它非常“强”？

那么，是否有可能以更少的“麻烦”实现相同的目标，或者这几乎是为任何敏感数据实现“最高安全性”的最佳方法？

/**
 * Generate truly random string for broadcast_token
 * @param App\Models\User $user
 * @return string
 */
function broadcast_id(\App\Models\User $user) : string {
    $algorithm = 'sha512';
    $randomString = \Illuminate\Support\Str::random(127);
    $usernameHash = hash($algorithm, $user->username);
    $emailHash = hash($algorithm, $user->email);
    $firstNameHash = hash($algorithm, $user->first_name);
    $lastNameHash = hash($algorithm, $user->last_name);
    $timeHash = hash($algorithm, time());
    $hashedData = hash($algorithm, sprintf('%s:%s:%s:%s:%s', $usernameHash, $emailHash, $firstNameHash, $lastNameHash, $timeHash));
    return sprintf('%s%s', $randomString, $hashedData);
}

【问题讨论】：

或者只使用random_bytes()并将令牌与用户的元数据一起存储。
用户数不影响token的随机性。
您是在寻找随机的东西还是安全的东西？如果您只想生成一个令牌，也许您可以使用盐对用户名进行哈希处理。
如果你想要“安全”，那么你需要完全“随机”，它的额外好处是只需调用random_bytes()，而不是将所有这些 CPU 周期浪费在散列上。 255 个随机字节比 128 个确定性字节和 127 个随机字节更难猜测/破解。
如果你想要唯一性，也有UUIDs。根据您的数据库引擎，它可能会为您生成它们。

标签： php algorithm security random hash

【解决方案1】：

对于任何涉及敏感信息的操作，我需要一个令牌，它足够安全，可以用作广播频道。

好的。

创建 127 个字符的随机字符串

[剪辑]

所以我最终得到的是 255 个字符的字符串。这个令牌在每次登录时都会重新生成，所以它非常“强”？

你的目标是一个随机字符串，所以你从一个随机字符串开始？

这似乎很麻烦。

那么，是否有可能以更少的“麻烦”实现相同的目标，或者这几乎是为任何敏感数据实现“最高安全性”的最佳方法？

简单：

$token = bin2hex(random_bytes(32));

将一堆东西散列在一起只会给你的脚本增加一点计算开销，它并不能真正保证任何东西的安全。

使用 32 字节的随机字符串，在生成大约 2^128 个令牌后，您将有第一次冲突（50%）的概率。你这辈子都不会达到这个数字。

【讨论】：