用于密码哈希的非随机盐

Question

用于密码哈希的非随机盐我最近从这个问题中了解到，在下面的整个讨论中，我（我确信其他人也这样做）有点令人困惑：我一直称之为彩虹表，实际上称为哈希表。彩虹桌是更复杂的生物，实际上是Hellman Hash Chains的变种。虽然我认为答案仍然是相同的（因为它不归结为密码分析），但有些讨论可能有点偏差。问题是：“ 什么是彩虹表，它们是如何使用的？ ”通常，我总是建议使用加密强随机值作为salt，与哈希函数（例如密码）一起使用，例如防止彩虹表攻击。但实际上盐是随机的加密必要吗？在这方面，任何唯一值（每个用户唯一，例如userId）是否足够？实际上，它会阻止使用单个Rainbow Table来破解系统中的所有（或大多数）密码...... 但是缺少熵真的会削弱散列函数的加密强度吗？注意，我不是在问为什么要使用salt，如何保护它（它不需要），使用单个常量哈希（不要），或者使用什么样的哈希函数。无论盐是否需要熵。感谢所有答案到目前为止，但我想集中讨论我（有点）不太熟悉的领域。主要是对密码分析的影响 - 如果有人从密码数学PoV获得一些输入，我会非常感激。此外，如果还有其他未被考虑的向量，那也是很好的输入（参见@Dave Sherohman指向多个系统）。除此之外，如果您有任何理论，想法或最佳实践 - 请使用证据，攻击情景或经验证据来支持这一点。或者甚至是可接受的权衡的有效考虑因素......我对该主题的最佳实践（资本B资本P）很熟悉，我想证明这实际上提供了什么价值。编辑：这里有一些非常好的答案，但我认为正如@Dave所说，它归结为Rainbow Tables的常见用户名......以及可能不太常见的名称。但是，如果我的用户名是全局唯一的呢？不一定是我的系统唯一，但每个用户 - 例如电子邮件地址。没有动力为单个用户构建RT（正如@Dave强调的那样，盐不会保密），这仍然会阻止群集。唯一的问题是我可能在不同的网站上有相同的电子邮件和密码 - 但盐无论如何都不会阻止它。因此，它回归到密码分析 - 是否需要熵？（我目前的想法是从密码分析的角度来看没有必要，但这是出于其他实际原因。）

Answer 1

使用高熵盐对于安全地存储密码是绝对必要的。

拿我的用户名'gs'并将其添加到我的密码'MyPassword'给gsMyPassword。这很容易使用rainbow-table打破，因为如果用户名没有足够的熵，那么这个值可能已存储在rainbow-table中，特别是如果用户名很短。

另一个问题是您知道用户参与两个或更多服务的攻击。有许多常见的用户名，可能最重要的用户名是admin和root。如果有人创建了一个与最常见用户名有盐的彩虹表，他可以使用它们来破坏帐户。

他们曾经有过12位盐。12位是4096种不同的组合。这不够安全，因为现在很容易存储大量信息。这同样适用于4096个最常用的用户名。您的一些用户可能会选择属于最常见用户名的用户名。

我找到了这个密码检查器，它可以解析你密码的熵。密码中的较小熵（例如使用用户名）使得彩虹表更容易，因为它们试图至少覆盖所有低熵密码，因为它们更有可能发生。