如果攻击者知道盐对安全无用吗？答案

【问题标题】：Are salts useless for security if the attacker knows them?如果攻击者知道盐对安全无用吗？
【发布时间】：2009-07-08 14:26:12
【问题描述】：

假设我有一个这样设置的用户表：

CREATE TABLE `users` (
    `id` INTEGER PRIMARY KEY,
    `name` TEXT,
    `hashed_password` TEXT,
    `salt` TEXT
)

创建用户时，会生成一个随机生成的 salt，并将其与 get_hash(salt + plaintext_password) 之类的结果一起存储在数据库中。

我想知道如果恶意用户获得了这些数据，他们是否能够使用它来破解用户的密码？如果有，有什么方法可以预防？

【问题讨论】：

标签： security language-agnostic hash

【解决方案1】：

不，它们不是没用的。

只要您为每一行使用唯一的盐，盐就会防止减慢攻击。攻击者需要发起蛮力攻击，而不是对密码哈希使用rainbow tables。

如 cmets 中所述，您应确保盐的大小合理。

【讨论】：

问题询问攻击者是否知道盐
卢克的回答是假设攻击者知道盐。关键是，完全没有盐，攻击者可以在他们在网上找到的彩虹表中查找散列密码。添加盐后，攻击者必须自己进行暴力破解。
关键点：盐的大小必须选择得足够大，以至于攻击者不可能拥有足够大的彩虹表。显然 8 位盐不能绝对阻止彩虹表攻击，只需将所需的表大小最多增加 256 倍。128 位随机盐，otoh，现在和永远排除彩虹表。
@Mitch：预先计算最多 n 个字符的密码的所有可能的 MD5 哈希（举一个不安全的例子）很容易。加盐很好，因为不可能预先计算那么多密码*可能的盐的数量。盐没有隐藏。

【解决方案2】：

Salting 在 UNIX /etc/passwd 文件中被引入（或至少变得流行），该文件是世界可读的。通常假设破解者知道盐和加密密码。 salt的目的是减慢破解过程（因为相同的密码不会映射到相同的加密字符串）；它本身不是秘密。

【讨论】：

【解决方案3】：

了解盐可以进行蛮力攻击，但这并不意味着它毫无用处。 Salt 可以防止攻击者使用已经生成的彩虹表（您可以在网上找到）。

防止暴力破解的最佳方法就是使用长而复杂的密码。

【讨论】：

【解决方案4】：

如果攻击者知道盐、散列密码和散列算法，那么他们可以发起暴力字典攻击（或彩虹攻击）。

【讨论】：

盐通过对条目的独特性而不是通过保密来获得它们的力量。检查彩虹表上的维基百科条目，上面写着“A salt 通常与散列密码一起使用，以使这种攻击更加困难，通常是不可行的。”

【解决方案5】：

这应该让您了解它的工作原理。

假设您要加密一个单词“秘密”。加密后可以说它现在看起来像这样 00110010。

如果黑客知道加密算法，他们可以创建一个单词表及其对应的加密值。于是他们取了加密密码“00110010”并在表中查找。现在他们知道用于生成“00110010”的密码是“秘密”这个词。如果你先给这个词加盐，那么一个通用的查找表对黑客来说将毫无用处。（通用查找表是未加盐的字典单词及其加密值的表）

如果你先对单词加盐（“saltsecret”），现在加密后的值看起来会有所不同，黑客不会在查找表中找到它。

但是，他们仍然可以使用您的 salt 从头开始创建自己的查找表，最终他们将能够反转查找密码。

所以要回答这个问题，如果密码足够复杂，黑客需要很长时间才能弄清楚它们。您可以每年更换盐，他们将不得不重新开始创建表格。

【讨论】：

此外，如果您不使用盐（或使用共享盐），那么攻击者将知道散列“00110010”的每一行都有密码“secret”。如果您对每一行使用唯一的盐，那么每个用户都可能拥有相同的密码，而攻击者不会知道它。

【解决方案6】：

不，这不是一文不值。

要成功攻击一个帐户，攻击者需要知道该帐户的盐（每个帐户的盐应该不同）、使用的散列算法、和最终存储的密码散列。 p>

鉴于所有这些信息，您可以编写一个程序，不断尝试散列不同的潜在密码，直到找到匹配的密码。

如果它是一个坏盐（太简单或太短），这可以更快，因为程序可以使用彩虹查找表将最终存储的密码散列与散列的字符串相匹配，然后减去盐。但他们仍然需要所有信息。

如果它是一个共享盐，这很糟糕，因为攻击者会使用盐提前生成一个彩虹表，这对您系统上的任何帐户都有好处。

【讨论】：

【解决方案7】：

假设使用 GPU 进行 MD5、SHA1、SHA256 算法的蛮力攻击，吞吐量大于每秒 10 亿次尝试，SHA512 约为 300M/s。如果您使用其中一种算法，它会减慢使用彩虹表的黑客（可能性较小），但不会减慢使用暴力攻击的黑客（可能性较大）。它绝对不会保护你，它只是增加了一些针对过时的彩虹表的安全性（对于这些算法）。有一点总比没有好。

但是，如果您使用最强大的算法（例如 bcrypt），即使使用散列存储，盐也绝对值得，因为从时间上讲，蛮力是不可行的，所以彩虹是有意义的。

看看这个 article 总结一下：

如果您是用户：

确保您的所有密码都包含 12 个或更多字符，最好是更多。我建议采用密码短语，它不仅比密码（如果不输入密码）更容易记住，而且由于它们的长度，它还能非常安全地防止暴力破解。

如果您是开发人员：

仅使用 bcrypt 或 PBKDF2 来散列您需要确保安全的任何内容。这些新的哈希是专门设计用于难以在 GPU 上实现的。不要使用任何其他形式的哈希。几乎所有其他流行的哈希方案都容易受到商品 GPU 阵列的暴力破解，这些 GPU 每年只会变得更快、更并行和更容易编程。

由杰夫·阿特伍德发布

【讨论】：