更新：我最近从this question了解到，在下面的整个讨论中，我（我相信其他人也这样做）有点令人困惑：我一直称之为彩虹表，实际上称为哈希表。彩虹桌是更复杂的生物，实际上是Hellman Hash Chains的变种。虽然我认为答案仍然是相同的（因为它不归结为密码分析），但有些讨论可能有点偏斜。
问题是：“What are rainbow tables and how are they used?”
通常，我总是建议使用加密强随机值作为salt，与哈希函数（例如密码）一起使用，例如防止彩虹表攻击。
但盐实际上是加密必需的吗？在这方面，任何唯一值（每个用户唯一，例如userId）是否足够？实际上，它会阻止使用单个Rainbow Table破解系统中的所有（或大多数）密码...
但缺乏熵真的会削弱哈希函数的加密强度吗？
注意，我不是在问为什么要使用salt，如何保护它（它不需要），使用单个常量哈希（不要），或者使用什么样的哈希函数。登记/> 无论盐是否需要熵。
感谢大家到目前为止的答案，但我想集中讨论我（不太熟悉）的领域。主要是对密码分析的影响 - 如果有人从加密数学PoV中获得一些输入，我会非常感激
此外，如果还有其他向量没有被考虑过，那也是很好的输入（参见@Dave Sherohman指向多个系统）。
除此之外，如果您有任何理论，想法或最佳实践 - 请使用证据，攻击情景或经验证据来支持这一点。或者甚至是可接受的权衡的有效考虑......我对该主题的最佳实践（资本B资本P）很熟悉，我想证明这实际上提供了什么价值。
答案 0 :(得分：153)
传统上，Salt存储为哈希密码的前缀。这已经使任何具有访问密码哈希的攻击者知道。将用户名作为salt使用不会影响该知识，因此它不会影响单系统安全性。
但是，使用用户名或任何其他用户控制的值作为salt会降低跨系统安全性，因为在使用相同密码哈希算法的多个系统上具有相同用户名和密码的用户最终会得到相同的结果每个系统上的密码哈希。我不认为这是一个重大的责任，因为我作为攻击者，在尝试任何其他危害帐户的方法之前，会首先尝试使用目标帐户已在其他系统上使用过的密码。相同的哈希只能事先告诉我已知的密码可以工作，它们不会使实际的攻击变得更容易。 （请注意，快速比较帐户数据库会提供更高优先级的目标列表，因为它会告诉我谁是谁以及谁不重用密码。）
这个想法的更大危险是用户名通常被重复使用 - 例如，您关注的任何网站都会有一个名为“Dave”的用户帐户，而“admin”或“root”更为常见 - 这将使彩虹表的构建更容易，更有效地针对具有这些常用名称的用户。
通过在对密码进行散列之前添加第二个盐值（固定和隐藏或像标准盐一样暴露）可以有效地解决这两个缺陷，但是，此时，您可能只是使用标准熵无论如何，不要将用户名加入其中。
编辑添加：很多人都在谈论熵以及盐中的熵是否重要。它是，但不是因为大多数评论似乎都在思考。
一般的想法似乎是熵很重要，因此攻击者难以猜测盐。这是不正确的，事实上，完全无关紧要。正如各种人多次指出的那样，受盐影响的攻击只能由拥有密码数据库的人进行，而拥有密码数据库的人只能查看每个帐户的盐是什么。无论是否可猜，当你可以轻易查找它时无关紧要。
熵重要的原因是避免盐值聚集。如果盐基于用户名，并且您知道大多数系统都有一个名为“root”或“admin”的帐户，那么您可以为这两种盐制作彩虹表，它将破解大多数系统。另一方面，如果使用随机的16位盐并且随机值具有大致均匀分布，则需要所有2 ^ 16种盐的彩虹表。
这不是为了防止攻击者知道个人帐户的盐是什么，而是为了不给他们一个盐的大而胖的目标，这个目标将用于大部分潜在目标。
答案 1 :(得分：29)
使用高熵盐绝对需要安全地存储密码。
取我的用户名'gs'并将其添加到我的密码'MyPassword'给gsMyPassword。这很容易使用rainbow-table打破，因为如果用户名没有足够的熵，那么这个值可能已存储在rainbow-table中，特别是如果用户名很短。
另一个问题是您知道用户参与两项或多项服务的攻击。有许多常见的用户名，可能最重要的用户名是admin和root。如果有人创建了一个与最常见用户名有盐的彩虹表，他可以使用它们来破坏帐户。
They used to have a 12-bit salt。 12位是4096种不同的组合。这不够安全，因为that much information can be easily stored nowadays。这同样适用于4096个最常用的用户名。您的一些用户可能会选择属于最常用用户名的用户名。
我发现这个password checker可以解析您密码的熵。在密码中使用较小的熵（例如使用用户名）可以使rainbowtables更容易，因为它们试图覆盖至少所有低熵的密码，因为它们更有可能发生。
答案 2 :(得分：8)
确实，单独的用户名可能会有问题，因为人们可能会在不同的网站之间共享用户名。但如果用户在每个网站上有不同的名称，那应该是没有问题的。那么为什么不在每个网站上使其独一无二。像这样隐藏密码
散列函数（ “www.yourpage.com /” +用户名+ “/” +密码）
这应该可以解决问题。我不是密码分析的大师，但我确信我们不使用高熵的事实会使散列变得更弱。
答案 3 :(得分：7)
我喜欢同时使用两种：高熵随机每记录盐，加上记录本身的唯一ID。
虽然这对字典攻击等的安全性没有太大帮助，但它确实消除了有人将他们的盐和哈希复制到另一条记录以便用自己的密码替换密码的边缘情况。
（不可否认，很难想到这种情况适用的情况，但在安全方面，我认为腰带和牙套没有任何伤害。）
答案 4 :(得分：3)
散列函数的强度不是由其输入决定的！
使用攻击者已知的盐显然会使构建彩虹表（特别是对于 root 等硬编码用户名）更具吸引力，但它不会削弱哈希< / em>的。使用攻击者不知道的盐将使系统更难攻击。
用户名和密码的串联可能仍然提供智能彩虹表的条目，因此使用散列密码存储的系列伪随机字符的盐可能是更好的主意。举个例子，如果我有用户名“potato”和密码“beer”，你的哈希的连接输入是“potatobeer”，这是彩虹表的合理条目。
每次用户更改密码时更改盐可能有助于抵御长时间的攻击，执行合理的密码策略也是如此，例如：混合情况，标点符号，最小长度， n 周后的变化。
但是，我想说你选择的摘要算法更重要。例如，对于生成彩虹表而不是MD5的人来说，使用SHA-512会更加痛苦。
答案 5 :(得分：3)
如果盐已知或容易猜到，您没有增加字典攻击的难度。甚至可以创建一个修改过的彩虹表，其中考虑了“恒定”的盐。
使用独特的盐会增加BULK字典攻击的难度。
具有独特的加密强盐值是理想的。
答案 6 :(得分：3)
我会说，只要每个密码的盐不同，你就可以了。盐点，是你不能使用标准的彩虹表来解决数据库中的每个密码。因此，如果您对每个密码应用不同的盐（即使它不是随机的），攻击者基本上必须为每个密码计算一个新的彩虹表，因为每个密码使用不同的盐。
使用具有更多熵的盐并没有多大帮助，因为假设这种情况下的攻击者已经拥有了数据库。由于您需要能够重新创建哈希，因此您必须已经知道盐是什么。因此，您无论如何都必须存储盐或构成盐的值。在像Linux这样的系统中，获取盐的方法是已知的，因此没有使用秘密盐。您必须假设具有您的哈希值的攻击者也可能知道您的盐值。
答案 7 :(得分：1)
Salt应该具有尽可能多的熵以确保如果给定的输入值被多次散列，那么得到的散列值将尽可能接近，总是不同。
在盐中使用尽可能多的熵的不断变化的盐值将确保散列（例如，密码+盐）的可能性将产生完全不同的散列值。
盐中的熵越少，生成相同盐值的可能性就越大，因此生成相同哈希值的可能性就越大。
当输入已知并且允许字典攻击或彩虹表如此有效的“常量”时，散列值的性质是“常量”。通过尽可能多地改变得到的散列值（通过使用高熵盐值）确保散列相同的输入+随机盐将产生许多不同的散列值结果，从而击败（或至少大大降低彩虹表的有效性）攻击。
答案 8 :(得分：-1)
熵是盐值。
如果在盐后面有一些简单且可重复的“数学”，那么盐就不一样了。只是添加时间值应该没问题。