为什么我们使用“盐”来保护我们的密码？

Question

我正在阅读this tutorial，我遇到了以下关于加密的讨论。最后写着

在最后一行，我们用密码对盐进行了哈希处理，得到了一个 实际上是加密的密码 无法破解

但在我看来，同时拥有encrypted_password 和salt 的黑客可以像使用salt 一样执行“彩虹”技巧。

那么，我哪里错了？

谢谢！

$ rails console
>> require 'digest'
>> def secure_hash(string)
>>   Digest::SHA2.hexdigest(string)
>> end
=> nil
>> password = "secret"
=> "secret"
>> encrypted_password = secure_hash(password)
=> "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> submitted_password = "secret"
=> "secret"
>> encrypted_password == secure_hash(submitted_password)
=> true

这里我们定义了一个函数，叫做 使用加密的secure_hash 散列函数称为 SHA2，是 SHA 系列哈希函数，我们 通过摘要包含到 Ruby 中 library.7 知道并不重要 这些哈希函数究竟是如何工作的； 为了我们的目的，重要的是 他们是单向的：没有 计算上易于处理的方法 发现

2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b 是字符串的 SHA2 哈希 “秘密”。

但是，如果您考虑一下，我们 还有一个问题：如果攻击者 曾经掌握过散列密码， 他还有机会 发现原件。为了 例如，他可以猜到我们使用了 SHA2，所以写一个程序 将给定的哈希值与哈希值进行比较 潜在密码的值：

>> hash = "2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b"
>> secure_hash("secede") == hash
=> false
>> secure_hash("second") == hash
=> false
>> secure_hash("secret") == hash
=> true

所以我们的攻击者有一个匹配 - 坏消息 对于任何具有密码“秘密”的用户。 这种技术被称为彩虹 攻击。

为了阻止潜在的彩虹攻击，我们 可以使用盐，这是一种不同的 每个用户的唯一字符串。8 一个 （几乎）确保的常用方法 唯一性是散列当前时间 （在 UTC 中与时区无关） 连同密码，这样两个 只有在以下情况下，用户才会有相同的盐 它们的创建方式完全相同 时间和密码相同。让我们 看看这是如何使用的 中定义的secure_hash函数 上面的控制台：

>> Time.now.utc
=> Fri Jan 29 18:11:27 UTC 2010
>> password = "secret"
=> "secret"
>> salt = secure_hash("#{Time.now.utc}--#{password}")
=> "d1a3eb8c9aab32ec19cfda810d2ab351873b5dca4e16e7f57b3c1932113314c8"
>> encrypted_password = secure_hash("#{salt}--#{password}")
=> "69a98a49b7fd103058639be84fb88c19c998c8ad3639cfc5deb458018561c847"

在最后一行，我们用密码对盐进行了哈希处理，得到了一个 实际上是加密的密码 不可能破解。 （为清楚起见， 散列函数的参数是 通常用--分隔。）

Answer 1

彩虹表的计算成本很高。没有盐，您可以构建一个可以重复使用的彩虹表，因为密码“密码”将始终产生相同的哈希（md5=5f4dcc3b5aa765d61d8327deb882cf99，sha1=5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8），因此很容易在密码数据库中识别。

对于盐，您必须为遇到的每种盐计算一个彩虹表。一个大小合适的盐，比如 32 位（理想情况下，128 位甚至更多），意味着您必须为要破解的每个密码计算一个彩虹表，从而大大违背了它的目的。

Answer 2

Salt 是为了阻止某人预先计算“反向”查找表，使攻击者可以快速找到导致目标哈希的密码。创建其中一个表在计算上的工作量与暴力破解目标密码空间一样多，因此只有在可以在多个目标上使用该表时才值得。

盐可以防止这种情况；攻击者在生成表时需要考虑盐，因此该表仅适用于单个目标，攻击者又恢复了蛮力。

Answer 3

是的，你是对的，如果有人知道你的算法和盐，他可以生成一个彩虹表。但是，生成彩虹表需要很长时间，因为允许的字符越多。

例如，如果您有一个由 10 个字符组成的密码，这些字符都是数字，那么您就有 10^10 种可能性。如果您允许使用大小写字母字符，则最多有 62^10 个可能性，只有 8.39 * 10^17 个排列；这仅适用于 10 个字符的密码，您还必须考虑低于或高于该长度的任何长度，具体取决于您允许的密码长度。

生成这样的表需要很长时间，而算法本身的彩虹表可能很容易获得，salt 会修改算法以使其成为您自己的，并且为此存在表的可能性非常低。

Answer 4

如果您使用 salt（即使它是公开的但对站点而言是唯一的），您将获得免受哈希字典的保护，其中经常使用的密码已经过哈希处理。

如果您的盐是安全的，那么他们就无法使用超级计算机对其进行暴力破解。他们必须使用您的服务器检查所有可能的密码（希望有某种形式的暴力保护）。