hash(hash()) 与加盐哈希

发布于 2024-10-08 16:25:44 字数 495 浏览 1 评论 0原文

自从引入 Rainbow 表以来，并且仅使用散列密码（例如：MD5）将密码存储在数据库不是最好的安全方式。

当人们谈论加盐哈希时，总是以这种方式使用它 hash(password . salt) 甚至 hash(hash(password) . salt)。

我不知道为什么要使用盐，并为每个密码添加额外的条目来存储盐？为什么我们不直接使用hash(hash(password))，甚至hash(hash(hash(password)))？

放盐是不是更安全？或者只是更复杂的感觉？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

木緿 2024-10-15 16:25:44

您可以根据 hash(hash(pwd)) 的字典构建彩虹表，所需时间仅为 hash(pwd) 的两倍（甚至更少，因为性能主要与磁盘写入有关），而且它甚至不会更大。使用盐会极大地扩大表所需的大小，直至达到不切实际的程度。

此外（更重要的是），用户通常拥有相同的密码。如果每个用户没有单独的盐，如果您破解了一个用户的密码，那么您就破解了具有相同密码的所有其他用户。

回复收藏 0 原文

雨落星ぅ辰 2024-10-15 16:25:44

为了简单起见，我们假设每个人都使用数字作为密码。

如果每个人都使用 8 位数字作为密码，那就有 100,000,000 种可能性。如果你想破坏系统，你需要散列所有这些可能性。如果你有一个“哈希的哈希的哈希”，你仍然只需要对这 100,000,000 种可能性进行哈希 - 只是以稍微复杂的方式。

现在假设我们也有一个 4 位数的盐。现在，可能性不再是 100,000,000 种，而是 1,000,000,000,000 种……我们为潜在攻击者提供了 10,000 倍的工作量，而不是 3 倍的工作量。

基本上，可以将盐视为一种人为地使每个人的密码更长的方法，从而扩展字典攻击必须起作用的空间。

编辑：需要明确的是，鉴于盐也是以纯文本形式提供的，您仍然只有 100,000,000 种可能性来尝试攻击任何一个哈希。然而，这意味着在尝试了一个密码的这些可能性之后，攻击者将没有任何有用的信息来攻击另一个密码。如果没有盐，攻击者可以创建包含 100,000,000 种可能性的字典，然后仅根据哈希值就知道数据库中的所有密码。换句话说，盐有助于防止批量攻击。它们还意味着您无法预先生成字典：为了有效地攻击单个密码，您必须事先知道盐。如果没有盐，您可以在访问哈希值本身之前计算每个可能的密码的哈希值。

回复收藏 0 原文

紫瑟鸿黎 2024-10-15 16:25:44

如果您不使用盐，那么攻击者可以构建一个彩虹表来攻击数据库中的每个密码。如果没有盐，多次散列并不能保护您，因为彩虹表的工作原理是按照您所描述的方式将散列链接在一起：hash(hash(password))。

如果为每个用户添加随机盐，那么攻击者就无法重复使用同一个表来破解两个密码，因此他们的工作变得更加困难。作为一个额外的好处，如果使用盐，具有相同密码的两个用户将散列为不同的值。

你迭代哈希的想法仍然很好，但你也需要盐。如果这样做：

function hashPassword(password, salt) {
    result = hash(salt . password)
    for (i = 0; i < 1000; i++) {
        result = hash(salt . result)
    }
    return result
}

那么攻击者的工作就会困难 1000 倍，而对合法用户的影响可以忽略不计。请注意，攻击者每秒可以在一台低端计算机上测试数百万个候选密码 - 哈希函数的设计速度很快。这 1000 次迭代循环可以将可行的攻击变成需要 100 年或更长时间的攻击。当计算机在 18 个月内加速时，只需将迭代次数更改为 2000。salt

、哈希算法和迭代计数不需要保密，可以与计算的哈希值一起存储在数据库中。您可以选择固定的迭代次数和哈希算法，但盐必须为每个用户随机生成。

If you don't use a salt then an attacker can build a single rainbow table can be used to attack every password in your database. Hashing multiple times does not protect you without a salt, because rainbow tables work by chaining hashes together in exactly the way you describe: hash(hash(password)).

If you add a random salt for each user then the attacker cannot re-use the same table to crack two passwords so their work becomes much harder. As an added benefit, two users with the same password will hash to different values if a salt is used.

Your idea of iterating the hash is still good, but you need the salt too. If you do this:

function hashPassword(password, salt) {
    result = hash(salt . password)
    for (i = 0; i < 1000; i++) {
        result = hash(salt . result)
    }
    return result
}

then you make the attacker's work 1000 times harder with a negligible effect on legitimate users. Note that attackers can test millions of candidate passwords each second on a single, low-end computer - hash functions are designed to be fast. This 1000 iteration loop can change a feasible attack into one that will take 100 years or more. When computers speed up in 18 months time just change the number of iterations to 2000.

The salt, hashing algorithm and iteration count do not need to be secret and can be stored in your database alongside the computed hash. You can choose a fixed iteration count and hash algorithm, but the salt must be randomly generated for each user.

回复收藏 0 原文