代码之家 › 专栏 › 技术社区 › MiffTheFox

如果攻击者知道盐对安全是无用的吗?

hash language-agnostic security

MiffTheFox · 技术社区 · 16 年前

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

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

当一个用户被创建时,一个随机生成的salt会被生成并存储在数据库中,与类似的结果一起 get_hash(salt + plaintext_password) .

我想知道,如果一个恶意用户获得了这些数据,他们是否能够使用它来破解用户的密码?如果是这样的话,有什么办法可以避免这种情况?

7 回复 | 直到 11 年前

LukeH 16 年前

不,它们不是无用的。

只要每行使用一种独特的盐,盐就会防止放慢进攻速度。攻击者将需要进行暴力攻击,而不是使用 rainbow tables 密码哈希。

正如评论中提到的,您应该确保盐的大小是合理的。

mfx 16 年前

salting是在unix/etc/passwd文件中引入的(或者至少使其流行),它是世界可读的。通常假定破解程序知道salt和加密密码。salt的目的是减慢破解过程(因为同一密码不会映射到同一加密字符串);它是不秘密本身。

Zifre 16 年前

知道盐可以做一个野蛮的力量攻击,但这并不意味着它是无用的。salt防止攻击者使用已经生成的彩虹表(您可以在Web上找到)。

防止暴力强迫的最好方法就是使用长而复杂的密码。

Mitch Wheat 16 年前

如果攻击者知道salt、散列密码和散列算法,那么他们可以进行暴力字典攻击(或彩虹攻击)。

Kelly 16 年前

这应该让你了解它是如何工作的。

假设你想加密一个单词“秘密”。加密后,假设它现在看起来像这个00110010。

如果黑客知道加密算法,他们可以创建一个单词表及其相应的加密值。所以他们把加密的密码“00110010”拿到表格里。现在,他们知道用于生成“00110010”的密码是“秘密”一词。如果先对该词加盐,那么一般的查找表对黑客来说将是无用的。(通用查找表是由未加密字典单词及其加密值组成的表)

如果你先对这个词加盐(“saltsecret”),那么加密后的值看起来就不同了,黑客在查找表中找不到它。

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

因此,要回答这个问题,如果密码足够复杂,黑客要花很长时间才能弄清楚。你可以每年更换食盐,他们必须重新开始制作一张桌子。

Joel Coehoorn 16 年前

不,这不是毫无价值的。

要成功攻击一个帐户,攻击者需要知道该帐户的salt(每个帐户的salt应该不同),使用的哈希算法, 和最后存储的密码哈希。

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

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

如果是共享 salt,这很糟糕,因为攻击者会提前使用salt生成一个彩虹表,这对系统中的任何帐户都是有益的。

Nicolas Labrot 11 年前

假设使用gpu的md5、sha1、sha256算法的暴力攻击的吞吐量大于每秒10亿次尝试,sha512的吞吐量约为300m/s。如果使用其中一种算法,它将减慢使用彩虹表的黑客的速度(可能性较小),但不会减慢使用暴力攻击的黑客的速度(可能性更大)。它肯定不会保护你,它只是增加了一点安全,以防过时的彩虹表(这些算法)。有一点总比没有好。

但是,如果使用最强大的算法(如bcrypt),即使使用哈希存储,salt也绝对值得,因为从时间角度来看,蛮力是不可行的,所以彩虹是有意义的。

看看这个 article 总结一下:

如果您是用户:

确保你所有的密码都是12个字符或更多,理想情况下更多。我建议采用pass短语,这不仅比密码(如果不是类型的话)更容易记住,而且由于其长度的原因,完全可以防止野蛮的强制。

如果您是开发人员:

专门使用bcrypt或pbkdf2散列需要安全的任何内容。这些新的哈希是专门设计的,很难在GPU上实现。不要使用任何其他形式的哈希。几乎所有其他流行的散列方案都容易受到商品gpu数组的野蛮强制,而商品gpu数组每年只能更快、更并行、更容易编程。

Jeff Atwood发布