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