我目前正在编写一个程序，其中一部分涉及安全地创建密码哈希以存储在数据库中，我遇到了phpass框架，这似乎是强烈推荐的。在 phpass 中，他们似乎竭尽全力生成尽可能真正随机的盐以用于散列（例如，从 /dev/urandom 读取）。
我的问题是，与简单地使用相比，这样做有什么好处uniqid()？这难道不是简单地确保用于哈希的盐彼此不同而不是随机的吗？使用真正随机的盐实际上不会比使用独特的盐更糟糕，因为它可能会产生冲突而 uniqid() 不会？
编辑：我的问题不是关于计算机环境中是否存在“真正的”随机性，所以也许我措辞有点错误，但我的问题更多的是“更多”随机盐是否比更多唯一性有任何好处作为盐。
我试图找到一些漏洞利用先例的参考（并且正在挣扎！），但是与 uniqid() 产生的随机值相反，加密随机盐的想法是为了帮助防止对加密方案的攻击密文的方式。由伪随机数生成器生成的具有可预测模式的盐（例如唯一 ID）会消除密文中的一些可变性，当然，在密码学中，您正在寻找不可预测性。
当然，如果在您选择的框架（即 .NET 中的 RNGCryptoServiceProvider）中有一个加密安全的随机数生成器可供您使用，那么您会选择它而不是更可预测的模式。我会看看我是否能找到一些好的先例或白皮书。
在 PHP 中，该uniqid()函数根据当前时间计算其结果。这有助于确保值是唯一的，因为没有两次发生两次，但是这不适用于多个服务器，因为它纯粹是基于时间的。使用基于时间的东西是不好的，因为可以产生的不同uniqid()值的数量非常有限。假设 PHP 已经使用了 25 年，计算出来的时间为 7.89e+14 微秒，因此uniqid()会产生相同数量的 for 值。
这是一个非常大的数字，但是假设我们能够获得真正随机的盐，碰撞的机会实际上远低于使用uniqid(). 可以用作盐的可能字符有：
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
这意味着我们有 64 个不同的字符可用于 22 个字符的长盐，计算出大约 5.44e+39 个不同的组合。
所以基本上，在尝试制作独特的东西时，它实际上不如使用随机源时的独特。
迈克，正如我在另一个答案中所说，我认为这不是盐的问题，但如果您真的担心真/伪随机性，您可以使用 random.org 中的数字。 查看区别，a 并查看如何在 PHP 中获取真正的随机数。
我认为这无关紧要，因为盐也必须与散列密码一起存储，因此攻击者无论如何都会得到盐，并且攻击将是相同的，无论您如何生成盐。
（OT 讨论：我认为我没有看到使用 salt 存储密码的巨大优势——一旦攻击者获得特定哈希密码的 salt，他无论如何都可以进行字典攻击......它会更慢，因为攻击者必须重新哈希每个密码盐的字典，但是.. md5() 快得要命，如果攻击需要 5 分钟或半天，真正的区别是什么......我觉得有盐比没有盐更安全。）
编辑 - 讨论结论：salt 在破解密码所需的时间上有很大的不同，但不要使用 md5() 来散列密码！使用非常慢的散列函数，比如 bcrypt()，或者，如果你需要使用 md5()，调用它数千次！