密码哈希的非随机盐

更新：我最近从这个问题中学到，在下面的整个讨论中，我（而且我相信其他人也这样做）有点令人困惑：我一直称其为Rainbow表的实际上是一个哈希表。彩虹桌是更复杂的生物，实际上是Hellman哈希链的变体。尽管我相信答案仍然是相同的（因为它不能归结为密码分析），但其中的某些讨论可能有些偏斜。
问题是：“ 什么是彩虹桌？如何使用它们？ ”

通常，我总是建议使用加密强度高的随机值作为盐，与哈希函数（例如，密码）配合使用，例如，防止Rainbow Table攻击。

但是，实际上在密码学上盐必须是随机的吗？在这方面，任何唯一值（每个用户唯一，例如userId）是否足够？实际上，这将防止使用单个Rainbow Table破解系统中的所有（或大多数）密码...
但是缺乏熵真的会削弱哈希函数的加密强度吗？

注意，我不是在问为什么使用盐，如何保护它（不需要），使用单个常量哈希（不要）或要使用哪种哈希函数。
只是盐是否需要熵。

到目前为止，感谢所有人提供的答案，但我想重点介绍一下我不太熟悉的领域。对密码分析的主要影响-如果有人从密码数学PoV中获得一些输入，我将不胜感激。
另外，如果还没有考虑其他向量，那也是很好的输入（请参阅多个系统上的@Dave Sherohman点）。
除此之外，如果您有任何理论，想法或最佳实践，请提供证明，攻击场景或经验证据作为支持。甚至是可以接受折衷的合理考虑...我对这个问题的最佳实践（B资本P大写）很熟悉，我想证明这实际上提供了什么价值。

编辑：这里有一些非常好的答案，但是我认为正如@Dave所说的，归结于Rainbow Tables的常见用户名...以及可能不太常见的名称。但是，如果我的用户名是全局唯一的怎么办？对于我的系统而言，不一定是唯一的，但对于每个用户而言，例如，电子邮件地址。
没有动力为单个用户建立RT（正如@Dave所强调的那样，salt不会保密），并且这仍然可以防止群集。唯一的问题是，我在不同的站点上可能拥有相同的电子邮件和密码-但无论如何，萨尔特不会阻止它。
因此，可以归结为密码分析-是否需要熵？（我目前的想法是，从密码分析的角度来看这不是必需的，但是从其他实际原因出发。）

传统上，Salt是作为哈希密码的前缀存储的。这已经使任何有权访问密码哈希的攻击者都知道。使用用户名是否为salt不会影响该知识，因此不会对单系统安全性产生影响。

但是，将用户名或任何其他用户控制的值用作salt会降低跨系统安全性，因为在多个使用相同密码哈希算法的系统上具有相同用户名和密码的用户最终将在每个系统。我认为这不是重大责任，因为作为攻击者，我将在尝试以其他方式破坏帐户的方式之前，先尝试使用已知已在其他系统上使用的目标帐户的密码。相同的哈希只会事先告诉我已知的密码会起作用，它们不会使实际的攻击变得更容易。（不过，请注意，对帐户数据库进行快速比较会提供更高优先级的目标列表，因为它会告诉我谁是谁以及谁在不使用密码。）

这种想法带来的更大危险是，通常会重复使用用户名-例如，几乎您希望访问的任何站点都会有一个名为“ Dave”的用户帐户，而“ admin”或“ root”更为常见-这会使以这些通用名称为目标用户的彩虹表的构建更加容易和有效。

这两个漏洞都可以通过在对哈希值进行哈希处理之前在密码中添加第二个盐值（固定的，隐藏的或暴露的，类似于标准盐）来有效地解决，但是，此时，您也可以使用标准熵盐来代替使用用户名的过程。

编辑添加： 很多人都在谈论熵以及盐中的熵是否重要。它是，但并非出于大多数原因，似乎并非如此。

人们普遍认为，熵很重要，因此攻击者很难猜出盐。这是不正确的，实际上是完全不相关的。正如许多人多次指出的那样，受盐影响的攻击只能由具有密码数据库的人进行，而具有密码数据库的人只能查看每个帐户的盐是什么。何时可以平常查找它，是否可猜测都无关紧要。

熵很重要的原因是要避免盐值的聚类。如果盐基于用户名，并且您知道大多数系统都有一个名为“ root”或“ admin”的帐户，则可以为这两种盐创建一个彩虹表，它将破解大多数系统。另一方面，如果使用随机的16位盐，并且随机值具有大致均匀的分布，则您需要一个彩虹表来表示所有2 ^ 16种可能的盐。

这并不是要防止攻击者知道个人帐户的食盐是什么，不是要给他们提供单一盐的大而胖的目标，该目标将在相当大的潜在目标中使用。

为了安全地存储密码，绝对需要使用高熵盐。

以我的用户名“ gs”并将其添加到我的密码中，“ MyPassword”为gsMyPassword。使用彩虹表很容易破坏这一点，因为如果用户名没有足够的熵，则可能是该值已存储在彩虹表中，尤其是在用户名较短的情况下。

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

他们曾经有12位盐。12位是4096种不同的组合。这不够安全，因为如今可以轻松存储大量信息。4096个最常用的用户名也是如此。您的一些用户可能会选择一个属于最常见用户名的用户名。

我找到了这个密码检查器，可以计算出您的密码的熵。密码的熵较小（例如通过使用用户名），使得Rainbowtables尝试覆盖至少所有熵较低的密码，因为它们很可能会出现，因此彩虹表要容易得多。

确实，由于用户可能会在不同的网站之间共享用户名，因此仅用户名就可能会出现问题。但是，如果用户在每个网站上使用不同的名称，则应该毫无问题。那么，为什么不只是在每个网站上都使其独特。像这样散列密码

哈希函数（“ www.yourpage.com/"+用户名+” /“ +密码）

这应该可以解决问题。我不是密码分析专家，但是我确信我们不使用高熵这一事实会使哈希值变弱。

我喜欢同时使用这两种方法：每条记录的高熵随机盐，以及记录本身的唯一ID。

尽管这并没有增加对字典攻击等的安全性，但是它确实消除了附带情况，即有人将自己的盐和哈希值复制到另一条记录，目的是用自己的口令替换口令。

（诚​​然，很难想到这种情况适用的情况，但是在安全方面，我看不出皮带和牙套有什么危害。）

如果盐是已知的或容易猜测的，则您没有增加词典攻击的难度。甚至有可能创建一个修改后的彩虹表，该表考虑“恒定”盐。

使用独特的盐会增加批量字典攻击的难度。

具有独特的，加密强度高的盐值将是理想的。

我想说的是，只要每个密码的盐都不同，您可能就可以了。加盐的要点是，您不能使用标准的Rainbow表来解决数据库中的每个密码。因此，如果您对每个密码使用不同的盐（即使它不是随机的），则攻击者基本上必须为每个密码计算一个新的Rainbow表，因为每个密码使用不同的盐。

使用具有更大熵的盐并没有多大帮助，因为在这种情况下，假定攻击者已经拥有数据库。由于您需要能够重新创建哈希，因此您必须已经知道盐是什么。因此，无论如何，您必须存储盐或组成盐的值。在像Linux这样的系统中，获取盐的方法是已知的，因此拥有秘密盐是没有用的。您必须假设拥有您的哈希值的攻击者可能也知道您的盐值。

哈希函数的强度不取决于其输入！

使用攻击者已知的盐显然会使构建彩虹表（尤其是对于像root这样的硬编码用户名）更具吸引力，但不会削弱哈希值。使用攻击者不知道的盐将使系统更难以攻击。

用户名和密码的连接可能仍会提供一个智能彩虹表的条目，因此，使用一系列带有哈希值密码的伪随机字符的盐存储起来，可能是一个更好的主意。举例说明，如果我有用户名“ potato”和密码“ beer”，则哈希的串联输入为“ potatobeer”，这是彩虹表的合理输入。

每次用户更改密码时更改盐值可能会有助于克服长时间的攻击，以及实施合理的密码策略（例如混合大小写，标点符号，最小长度，n周后更改）会有所帮助。

但是，我想说您选择摘要算法更为重要。例如，对于生成彩虹表的人来说，使用SHA-512比MD5会更痛苦。

Salt应该具有尽可能大的熵，以确保应该多次对给定的输入值进行哈希处理，结果哈希值将尽可能接近始终保持不同。

在盐中使用尽可能多的熵来使用不断变化的盐值将确保散列的可能性（例如，密码+盐）将产生完全不同的散列值。

盐的熵越小，生成相同的盐值的机会就越大，因此生成相同的哈希值的机会就越多。

当输入已知时，散列值是“常数”的本质是“字典”或“彩虹”表如此有效的“常数”。通过尽可能多地改变所得哈希值（通过使用高熵盐值）可确保对相同的输入+随机盐进行哈希处理将产生许多不同的哈希值结果，从而击败（或至少大大降低了）彩虹表攻击。

熵是Salt值的点。

如果盐后面有一些简单且可重现的“数学”，则与盐不存在一样。只需添加时间值就可以了。