Question

我知道有很多关于salting密码的博客，文章和问题，但有一点我无法找到答案：

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

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

我有一张这样的桌子：

Users
user_id | hashedPassword | salt

为什么攻击者难以确定此密码？难道他们不能只使用彩虹表，或蛮力来弄清楚盐，然后将盐附加到字典攻击中的每个单词上？

Answer 1

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

那怎么办？但无论如何这不是问题 - 假设攻击者知道盐。它的目的不是秘密，这就是你将它存储在哈希旁边的原因。

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

当然他们可以做到这一点，但他们必须为特定用户做这件事。他们不能分摊数据库中所有用户的工作量，也不能使用预先计算的哈希 - >密码映射表。

那，只有那是一个盐点。

Answer 2

他们可以做到这一点。因此，他们需要为每个密码生成一个新的彩虹表（或者为每个密码迭代每个字典条目）。

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

哦，通常认为有两种盐是好习惯。一个存储在数据库中，每个密码哈希是唯一的，一个存储在整个站点唯一的文件系统上。这样，如果数据库受到损害，就没有明显的担心，因为他们只使用了1/2盐。当然，如果文件系统遭到破坏，他们可以全部搞定，但如果文件系统遭到破坏，他们可以安装密码嗅探器和其他恶意软件......

我希望有帮助...

Answer 3

盐的关键不是要使单个密码更强。这是为了防止攻击者在攻击多个密码时扩大规模。使用salt，攻击者无法重复攻击另一个密码;他必须重复他的字典。

彩虹桌并不神奇;它们只是预先计算的表的特例，类似于简单的字典攻击，具有略微不同的时空模态。构建彩虹表意味着或多或少地通过完整的字典。如果预先计算的表可以使用它们来攻击多个密码，那么它就是攻击者的一个收获。如果密码是盐渍的，那么预先计算好的表格，无论彩虹与否，都不会获得任何东西。

话虽这么说，单个密码通常很弱并且可能是强制性的，因为平均密码将适合普通用户的大脑，因此，不能非常复杂。为了降低这种风险，应该使用重复或迭代的散列。盐在这里没有帮助（但它也没有害处）。有关详细信息，请参阅this answer。

Answer 4

嗯，对于一个他们不能使用预先计算的彩虹表来发现碰撞 - 攻击者必须使用盐生成他们自己的彩虹表。此外，假设每个用户都有不同的盐，那个彩虹表只适用于单个用户 - 使他们的工作更加困难。

Answer 5

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

Alpha 只是哈希密码并存储结果：

row: {
    passwordHash = Hash(password)
}

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

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

现在说你的对手已经知道你的一些用户正在使用密码："password"

要查找密码为"password"的 Alpha 中的所有用户，您只需计算一次"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使用户对哈希函数的结果具有唯一性来巧妙地回避此漏洞。

我希望有一天能帮助一些读者！