time() 是一个好的盐吗？

Question

我正在查看一些我自己没有编写的代码。该代码尝试使用 SHA512 对密码进行哈希处理，并仅使用 time() 作为盐。 time() 对于这个来说是太简单了还是这个代码安全？

感谢您的回答和评论。我在这里为新读者总结一下：

• 每个用户的盐应该不同，因此如果2个用户同时注册，他们的盐将不会是唯一的。这是一个问题，但不是一个大问题。
• 但盐不应该与用户有任何关系，所以 time() 不是一个好的盐。
• “使用随机、均匀分布、高熵盐。”——这太拗口了，那么什么代码可能生成随机、均匀分布、高熵盐呢？

好的，那么我用 32 个字符长的随机字符串替换 time() 怎么样？随机字符串可以通过对一组字母字符循环 32 次来生成。听起来不错吗？

Answer 1

简短回答：

不，time() 不是一个好的盐。

长答案：

^{从我对 Salt Generation 的回答中复制和开源软件}

什么是盐？

盐是添加到哈希算法输入的固定长度的随机字节集。

为什么加盐（或播种）哈希有用？

向哈希值添加随机盐可确保相同的密码会生成许多不同的哈希值。盐通常与哈希函数的结果一起存储在数据库中。
对哈希进行加盐处理有很多好处：

1. 加盐极大地增加了预计算攻击的难度/成本（包括彩虹表）< /里>
2. 加盐可确保相同的密码不会产生相同的哈希值。
   这可确保您无法确定两个用户是否具有相同的密码。而且，更重要的是，您无法确定同一个人是否在不同系统中使用相同的密码。
3. 加盐会增加密码的复杂性，从而大大降低密码的有效性字典- 和 生日攻击。 （只有当盐与哈希值分开存储时，这才是正确的）。
4. 适当的加盐大大增加了预计算攻击的存储需求，直到它们不再实用的程度。 （8 个字符区分大小写的字母数字密码，具有 16 位盐，哈希为 128 位值，将占用 略低于 200 艾字节，没有彩虹减少）。

盐不需要保密。

盐不是秘密密钥，而是盐通过使哈希函数特定于每个实例来“工作”。对于加盐哈希，不存在一个哈希函数，而是针对每个可能的盐值都有一个哈希函数。这可以防止攻击者攻击 N 个散列密码，而成本却低于攻击一个密码的 N 倍。这就是盐的重点。
“秘密盐”不是盐，它被称为“密钥”，这意味着您不再计算哈希值，而是计算消息验证码 (MAC)。计算 MAC 是一件棘手的事情（比简单地将键和值组合到哈希函数中要棘手得多），而且它完全是一个非常不同的主题。

对于每个使用它的实例，盐必须是随机的。这确保攻击者必须单独攻击每个加盐哈希。
如果您依赖盐（或加盐算法）的保密性，那么您就进入了通过模糊实现安全性< /a> （不起作用）。最有可能的是，您不会从盐保密中获得额外的安全性；你只会得到温暖而模糊的安全感。因此，它不但不会让您的系统更加安全，反而会分散您对现实的注意力。

那么，为什么盐必须是随机的？

从技术上讲，盐应该是唯一的。盐的要点是每个散列密码都是不同的。这意味着全世界。由于没有中央组织可以按需分配独特的盐，因此我们必须依赖下一个最好的方法，即使用不可预测的随机生成器进行随机选择，最好是在足够大的盐空间内以使得碰撞不可能发生（两个实例使用相同的盐）盐值）。

尝试从某些“可能是唯一的”数据（例如用户 ID）中获取盐是很诱人的，但此类方案通常会因一些令人讨厌的细节而失败：

1. 如果您使用例如用户 ID，一些攻击不同系统的坏人可能会集中其资源并为用户 ID 1 到 50 创建预先计算的表。用户 ID 是系统范围内唯一，但全球范围内不唯一。

2. 这同样适用于用户名：每个 Unix 系统都有一个“root”，但世界上有很多个 root。 “root”的彩虹表是值得付出努力的，因为它可以应用于数百万个系统。更糟糕的是，还有许多“bob”，其中许多人没有接受过系统管理员培训：他们的密码可能非常弱。

3. 唯一性也是暂时的。有时，用户会更改密码。对于每个新密码，必须选择一个新盐。否则，攻击者获得旧密码的哈希值和新密码的哈希值可能会尝试同时攻击两者。

使用从加密安全、不可预测的 PRNG 中获得的随机盐可能有点矫枉过正，但至少它可证明可以保护您免受所有这些危险。这并不是要阻止攻击者知道个人盐是什么，而是不要给他们提供将用于大量潜在目标的大而胖的目标。随机选择使目标尽可能薄。

结论：

使用随机、均匀分布的高熵盐。每当您创建新密码或更改密码时，请使用新的盐。将盐与散列密码一起存储。喜欢大盐（至少 10 个字节，最好是 16 个或更多）。

盐不会将坏密码变成好密码。它只是确保攻击者至少为他破解的每个坏密码付出字典攻击代价。

有用的来源：
stackoverflow.com：密码哈希值的非随机盐
Bruce Schneier：实用密码学（书）
Matasano 安全性：彩虹表就够了
usenix.org：Unix crypt 自 1976 年起就使用盐
owasp.org：为什么要加盐
openwall.com：盐

免责声明：
我不是安全专家。 （尽管此答案已由 Thomas Pornin 审阅）
如果任何安全专业人士发现问题，请发表评论或编辑此 wiki 答案。

至于什么似乎是随机盐的良好来源
^{另请阅读：什么是随机数生成最安全的种子？}
在没有专用的、基于硬件的随机生成器的情况下，获取随机数据的最佳方法是询问操作系统（在 Linux 上，这称为 /dev/random 或 /dev/ urandom [两者都有优点和问题，选择你的毒药]；在 Windows 上，调用 CryptGenRandom())

如果由于某种原因您无法访问上述随机源，请在PHP 你可以使用以下函数：
^{来自phpass v0.3}

<?php
/**
 * Generate pseudo random bits
 * @copyright: public domain
 * @link http://www.openwall.com/phpass/
 * @param int $length number of bits to generate
 * @return string A string with the hexadecimal number
 * @note don't try to improve this, you will likely just ruin it
 */
function random_bits($entropy) {
    $entropy /= 8;
    $state = uniqid();
    $str = '';
    for ($i = 0; $i < $entropy; $i += 16) {
        $state = md5(microtime().$state);
        $str .= md5($state, true);
    }
    $str = unpack('H*', substr($str, 0, $entropy));
    // for some weird reason, on some machines 32 bits binary data comes out as 65! hex characters!?
    // so, added the substr
    return substr(str_pad($str[1], $entropy*2, '0'), 0, $entropy*2);
}
?>

Answer 2

已更新

这不是一种真正好的盐，但可能足以击败除了最坚定和最足智多谋的攻击者之外的所有攻击者。好的盐的要求是：

• 每个用户的盐值不同
• ，长度足够长（至少 8 个字母数字字符），以使盐和（可能较弱）密码的连接太长，无法进行暴力攻击。

time() 值实际上不够长，因为它们有 10 个字符，但只有数字。

此外，有时两个用户在同一秒内创建时可能会获得相同的值。但只有当您遇到同一秒内自动创建许多用户的情况时，这才会成为问题。

无论如何，比完美的盐更重要的是使用良好的哈希函数，而 SHA512 是我们目前可用的最好的哈希函数之一。

Answer 3

这篇文章可能与您最初的问题有点偏离，但我希望您发现它有用；

安全就是要设置壁垒和障碍；纵深防守。没有真正安全的哈希解决方案，只有难以破解的解决方案。这就像在你的房子里安装防盗警报器和窗锁 - 让你的网站比其他人的网站更难被侵入。

加密算法的加盐只是安全问题的一小部分。单一盐仅仅意味着在尝试破解多个用户的密码时少了一件需要弄清楚的事情。低熵盐（例如服务器的时间）使其变得更难，而高熵盐则使其更难。使用其中哪一个，以及是否需要担心，主要取决于您所保护的数据的敏感性，以及您采取的其他安全措施。一个只提供选定城市的个性化天气预报的网站显然比包含您的家庭住址、母亲的婚前姓名、出生日期和其他可用于识别目的的信息的网站的敏感数据要少。

所以这就是问题所在；如果容易获得，高熵盐仍然是不好的盐。

在现实世界中，将盐存储在数据库中（随机或非随机）可能不如使用恒定盐并将其隐藏在无法通过网络浏览器访问的文件中，远离私人视线。虽然独特且高熵的盐很难猜测，但如果您允许从 MySql 上的任何服务器进行 root 登录并将密码设置为“password”，那么这并不重要！对比一下破解数据库与获得服务器的有效登录有多容易——这可能更难以离散地进行，因为您可以根据您的设置放置fail2ban和大量其他攻击向量观察程序。

您可以通过在数据库中存储包含用户特定盐的文件的位置（而不是盐本身）来组合这两种方法。是否需要同时破解文件系统和数据库取决于您尝试保护的数据的敏感性是否需要这种开销。

安全专家的另一种建议是将用户名存储在与密码不同的数据库（最好采用不同的技术）中，并使用 UUID 在两者之间进行引用。例如，同时使用 MySQL 和 SQLite。这意味着两个数据库都必须被破解（这也是为什么，为了举例而进入一个单独的兔子洞，您不应该将用户详细信息和信用卡号码存储在同一个数据库中，因为如果没有这些数据库就没有任何用处）另一个）。

请注意，SHA-512 和 Blowfish 等算法可以将盐作为其哈希的一部分返回。小心这些，就好像你存储了泄露算法的完整哈希值一样，这意味着黑客需要弄清楚的事情少了两件事（盐也泄露了算法）。

确保使用强密码和用户名，这样字典攻击就会失败；我知道 MD5 用户名/密码条目的所有 6 个字母数字组合的字典，并且我怀疑对于各种算法来说，还有更多可用的字典。随着低成本云和 CPGPU 计算的爆炸式增长，可用词典的大小和复杂性将呈爆炸式增长。

最终，最安全的方法永远不是以编程方式生成盐，而是要求用户通过 SSL 链接输入它以及用户名和密码（因此无法被窥探），但永远不要存储它。这是信用卡公司采取的方法；即信用卡上的 3 位 CSV 安全密钥，每次在线购买时都必须输入该密钥，因为它永远不应该存储在任何数据库中。如果您确实想生成盐，请将其单独发送给他们（例如通过短信或电子邮件），并仍然让他们每次手动输入。使用这种方法，虽然更安全，但您需要将复杂性与用户是否会停止使用该网站进行对比，因为您让他们很难被它打扰。

上述所有内容仍然依赖于这样一个事实：您还拥有针对会话劫持、跨站点脚本编写等的保护措施。如果我需要做的只是计算有效的 PHPSESSID，那么世界上最强的密码算法是无关紧要的。登录用户并劫持它！

我不是安全专家，但已尽可能多地阅读了这方面的内容。事实上，关于这个主题的书籍如此之多，这表明你的问题的答案到底有多大。

您可能想尝试的几本非常棒的书，我发现它们非常有价值：

Web 应用程序漏洞检测、利用、预防 - ISBN-13：978-1-59749-209-6

使用 Apache 防止 Web 攻击 - ISBN-13：978-0-321-32128-2

Answer 4

不，time() 不是一个好的盐

在身份验证方面最好不要重新发明轮子，而是回答您的问题，不。 time() 的问题是：

• 它是可预测的，并且与潜在可发现的事物相关。这些问题使得交叉匹配不同的哈希结果变得更加容易。
• 可能的值并不多。由于高阶位不会改变，因此它的盐比最初出现时更窄。
• 使用它会重复以前的错误。如果此应用是第一个使用time()作为盐的应用，那么至少它需要新的攻击。

Answer 5

是的。
看起来，unix 时间戳作为“成员自”字段存储在用户数据库中将是不错的盐。

然而，盐问题是最可以忽略不计的一个。
您还需要注意更多重要的事情：

1. 很可能密码、盐或哈希算法都不是您网站中最薄弱的部分。肯定是一些蹩脚的文件注入或 XSS 或 CSRF。所以，别小题大做。
   在典型的 Web 应用程序中谈论 32 个字符长的真正随机字符串就像谈论木制谷仓中的 32 英寸装甲门一样。

2. 说到密码，最重要是密码复杂性。对于弱密码，没有盐或散列算法，即使是超级巧妙、难以置信、困难的算法，也能有所帮助。要求用户使用复杂的密码是一件很痛苦的事情，但如果没有它，其他一切都会变得一团糟。
   因此，您首先关心的应该是密码复杂性。要求 12-16 个不同大小写的字符，包括数字和标点符号。

3. 至于盐，我认为使用时间没有任何好处，因为您必须将其与其他用户数据一起存储。最好使用电子邮件——它足够随机，而且无论如何你已经拥有它了。如果用户更改了电子邮件，请不要忘记重新哈希密码。 看来 unix timstamp 将是一个不错的盐，不需要使用电子邮件或其他任何东西。

更新
据我所知，很多人仍然无法理解这一点。
就像评论里那个人说的

许多用户使用弱密码（我们应该教育他们，或者至少继续尝试），但这不是借口；他们仍然值得良好的安全保障

毫无疑问，他们值得拥有。但用弱密码来完成任务。是。不可能。

如果您的密码很弱，那么没有盐可以保护它。

虽然盐对于在该主题上花费 10 KB 的文本来说并不是那么重要。

Answer 6

Salt 用于通过破坏密码和预先计算的哈希值之间的匹配来防止彩虹攻击。因此，盐的主要任务是使每个用户/密码记录都不同。只要盐对于不同用户来说是不同的，盐的随机化质量并不重要。

Answer 7

成员加入论坛/网站的日期通常是可以公开访问的，这与 time() 相同，因此使您的盐毫无用处。

Answer 8

不！切勿使用当前时间作为盐。您可以使用 java 中的“SecureRandom”之类的东西来生成安全的随机盐。始终使用不可预测的随机数作为盐。
使用时间作为盐只能在一定程度上帮助您消除冲突（因为两个用户可以同时输入相同的密码），但仍然使密码可恢复。

Answer 9

用户名应该足够了，也许还有注册时间戳，但您应该将其存储在数据库中的某个位置。无论如何，您用来加盐密码哈希的每个值都应该以某种方式存储，以便您可以重新计算哈希。

使用用户名+时间戳进行加盐是否足够安全？应该是的。为了破解 SHA512 哈希，通常使用彩虹表。用户名+时间戳应该是一个足够唯一的盐，所以网上不可能有一些彩虹表包含预先计算的带有密码的哈希值，这些哈希值是这样加盐的。