在Krebs on Security 上发布的这次采访中，有人提出并回答了这个问题：
BK：我听说有人说，如果 LinkedIn 和其他人对密码进行了加盐处理，或者为每个密码添加了一些随机性，那么你知道这可能不会发生，从而迫使攻击者花费更多资源来破解密码哈希。你同意吗？
Ptacek：这实际上是另一个误解，认为问题在于密码未加盐。UNIX 密码，自上世纪 70 年代以来，它们就被永远破解了，并且永远被破解了。密码中加盐的想法是 70 年代的解决方案。回到 90 年代，当人们闯入 UNIX 服务器时，他们会窃取影子密码文件并破解它。当您丢失服务器时，总是丢失该服务器上的密码。
Ptacek 并没有真正解释为什么会出现这种情况——他只是说盐在过去并没有阻止这种类型的攻击。
我的理解是，salt 只能防止密码哈希的预先计算，因为存储预先计算的哈希需要空间。但是，如果您破坏了系统，您将同时拥有盐和哈希。所以字典攻击哈希的时间并没有显着变化（只是盐与字典单词的额外连接）。
我的理解正确吗？
Krebs 跟进了这个问题，Ptacek 确实澄清了他的意思：
BK：好的。因此，如果弱点不在于加密算法的强度，也不在于散列密码中添加盐的缺乏，那么答案是什么？
Ptacek：在 LinkedIn 和许多其他网站的案例中，问题是他们使用了错误的算法。当他们需要使用密码散列时，他们使用加密散列。
在接下来的几段中，他还详细说明了原因。总而言之，SHA1，不管有没有盐，都太快了，不能用作密码哈希。它是如此之快，以至于当使用 GPU 或类似的东西进行计算时，你可以每秒暴力破解 10 万个哈希值。正如稍后在采访中详述的那样，LinkedIn 应该一直在使用 bcrypt，这是一种自适应哈希，可以将蛮力时间减慢到每秒 10 秒哈希的数量级。
我们先看盐的问题，再看速度的问题：
在攻击者访问多个密码哈希的常见情况下，盐可以极大地帮助抵御字典攻击。
如果没有盐，攻击者将对所有哈希进行排序。他将对密码字典中的第一个单词进行散列，并检查计算出的散列是否在他的被盗散列排序列表中。幸运的是，他已经可以访问多个帐户。
但是有了盐，他就得分别攻击每个账号。
彩虹表只是字典攻击的一个特例，因为它们在攻击之前已经完成并且可以使用了。
需要注意的是：将一个恒定的随机字符串粘贴到所有密码将使预建的彩虹表无用。但由于前面描述的并行性问题，这仍然是一个坏主意。
除了不使用盐之外，LinkedIn 还使用了非常快的哈希算法，并且可以在特殊硬件上执行以获得更高的速度。这种特殊的硬件不是奇特的，而是普通显卡的一部分。
Robert David Graham 发布了他的破解工作细节，包括性能数据：
使用 Radeon HD 7970 每秒 20 亿。6 [字符] 密码 [in] 500 秒 [...] 蛮力。
哈希算法的原始用例是签署文档。因此，快速是一个设计目标。
现代密码哈希算法的设计速度相对较慢。让它们变慢的一个简单方法是重复使用散列函数。ShaCrypt和BCrypt就是这样的算法。他们特别注意防止并行处理并抵抗单轮的原像攻击。
Scrypt更进一步：除了速度慢之外，它还需要大量内存（例如，默认配置为 16 MB）。专用硬件通常只能访问大约 1 KB 的快速内部存储器。访问核心内存很慢。因此，在硬件中构建一个快速的 scrypt 破解器会很快变得昂贵。
你是对的，但这并不能改变使用盐是必不可少的事实。在这种情况下，攻击者获得了散列密码，因此他们可以使用彩虹表或启动暴力破解或字典攻击。
彩虹表将在很短的时间内为您提供所有密码（不超过表中的大小和复杂性）。
同样，字典攻击会得到字典中的密码。
暴力破解可以让你快速获得简短而简单的密码，但快速获得较长密码所花费的时间变得如此令人望而却步，以至于使用长密码的用户仍然相对安全。
因此，盐消除了第一组可能性，迫使攻击者使用字典和蛮力解决方案——使用户更安全。
盐的作用是使彩虹表无用，这确实减慢了对密码的暴力破解尝试。
彩虹表的定义：
彩虹表是用于反转密码散列函数的预计算表，通常用于破解密码散列。
如果没有盐，攻击者可以轻松使用包含数百万个密码及其散列等效项的预生成彩虹表，并将其与密码进行比较。
使用盐，每个密码都需要攻击者生成一个全新的彩虹表。
它对字典攻击没有影响 - 简单、明显的基于字典的密码，如密码，无论有没有盐都可以很容易地破解。
但是应该使用盐。密码破解完全取决于时间/精力。没有密码/哈希是无敌的。这一切都是为了迫使攻击者在您的密码表上花费比他愿意花费更多的时间。