关于加盐密码的另一个问题

Question

我知道有大量关于加盐密码的博客、文章和问题，但我无法找到答案的一件事是：

如果我生成这样的密码哈希：

$salt = randomString
$password = $_POST['password'] 
hashedPassword = sha1($password.$salt)

并且我有一张表像这样：

Users
user_id | hashedPassword | salt

为什么攻击者破解这个密码如此困难？他们不能只使用彩虹表或蛮力来找出盐，然后将盐附加到字典攻击中的每个单词吗？

Answer 1

他们不能只使用彩虹桌吗？
或用蛮力找出盐，

那会如何工作？但无论如何这都不是问题——
假设攻击者知道盐。它的目的不是保密，这就是为什么你将它存储在哈希值旁边。

然后将盐附加到每个单词上
字典攻击？

当然他们可以这样做，但他们必须为特定用户这样做。他们无法将工作量分摊给数据库中的所有用户，也无法使用预先计算的哈希->密码映射表。

这，也只有这才是盐的意义所在。

Answer 2

他们可以做到这一点。其强大之处在于，他们需要为每个密码生成一个新的彩虹表（或迭代每个密码的每个字典条目）。

因此，单个密码的总计算时间仍然与普通盐相同。但是多个密码的总计算时间呈指数级增长......

哦，通常认为拥有两种盐是很好的做法。一种存储在数据库中，每个密码哈希都是唯一的，另一种存储在文件系统中，对于整个站点来说是唯一的。这样，如果数据库受到损害，也无需担心，因为它们只使用了 1/2 的盐。当然，如果文件系统受到损害，他们可以得到一切，但如果文件系统受到损害，他们可以安装密码嗅探器和其他讨厌的东西......

我希望这有帮助......

Answer 3

好吧，对于他们来说，他们不能使用预先计算的彩虹表来查找碰撞 - 攻击者必须使用盐生成自己的彩虹表。此外，假设每个用户都有不同的盐，那么彩虹表只适用于单个用户——这使得他们的工作变得更加困难。

Answer 4

加盐的目的不是让单个密码变得更强。这是为了防止攻击者在攻击多个密码时扩大规模。有了盐，攻击者就无法重复使用他的努力来攻击另一个密码；他必须重新修改他的字典。

彩虹桌并没有什么神奇之处。它们只是预计算表的一个特例，类似于具有稍微不同的时空模式的简单字典攻击。构建彩虹表或多或少意味着要浏览完整的字典。如果攻击者可以使用预计算表来攻击多个密码，那么他就会受益匪浅。如果密码被加盐，那么预先计算的表，无论是否是彩虹，都不会为他带来任何好处。

话虽这么说，单个密码通常很弱并且可以被暴力破解，因为普通密码适合普通用户的大脑，因此不能非常复杂。为了减轻这种风险，应该使用重复或迭代散列。盐在这里没有帮助（但也没有坏处）。有关详细信息，请参阅此答案。

Answer 5

让我们举一个简单的例子：我们有两个数据库，Alpha 和 Beta：

Alpha 只是对密码进行哈希处理并存储结果：

row: {
    passwordHash = Hash(password)
}

Beta 为每个用户创建一个随机值，并将其用作哈希函数输入的一部分：

row: {
    salt = RandomString(),
    passwordHash = Hash(password + salt)
}

现在假设您的对手事先知道您的某些用户正在使用密码：“password”

要查找 Alpha 中密码为 "password" 的所有用户，您只需计算一次 "password" 的哈希值。这是来自 SQL 的示例：

DECLARE @Hash INT; SET @Hash = Hash("password");
SELECT UserID FROM Users WHERE passwordHash = @Hash

由于它只涉及整数相等，因此它的效率与查询一样高。即使Alpha拥有数十万用户，它也会很快回归。

事实上，Beta 的哈希值在每个密码哈希值中都包含一个特定于行的随机值，因此您无法为其编写类似的高效查询。您能得到的最接近的结果是重新评估每行salt的散列函数（故意计算成本高昂）：

SELECT u.UserID FROM Users u WHERE u.passwordHash = Hash("password" + u.salt)

事实上，搜索已知密码的成本是如此之高应表明执行暴力攻击的成本有多大，即使该攻击是由常见密码字典或尝试将单词和数字混合在一起以按照人类的方式创建密码的算法引导的。

---

您已经知道 salt 是防御“彩虹表”攻击的一种措施，所以您的问题是......如何防御？

“彩虹表”已成为任何攻击的华丽术语，这些攻击提前计算常见密码和可能潜在密码的哈希值并将其存储在高效的查找表中。一旦构建了该表（这可能需要几个小时），您就可以迭代每个用户并查看他们的密码哈希是否在查找表中。如果是，您就会猜到该用户的密码。

Alpha 内的用户确实容易受到此类攻击。 Alpha 对于等效的密码将具有等效的哈希值，因此可以使用哈希表或彩虹表来反转哈希值。但是Beta巧妙地避开了这个漏洞，通过salt使哈希函数的结果对用户来说是唯一的。

我希望有一天这可以帮助一些读者！