使用“盐”真的好吗？答案

【问题标题】：Is using a 'salt' all that good?使用“盐”真的好吗？
【发布时间】：2010-10-22 07:25:00
【问题描述】：

我并没有声称自己是安全专家，但在我看来，添加盐并没有太大的不同。

例如，如果用户的密码是 john1970，salt 是 123456，这意味着密码是 123456john1970，而这对于攻击者来说会更加困难（如果使用字典攻击，例如彩虹表），攻击者很可能猜到第一部分是盐。我发现使用非标准方法（比如用一些键进行异或运算或对字符代码应用一些简单的数学运算）更有效。我知道你们中的大多数人可能不会同意我的观点，但这对我来说似乎更有意义。

你的意见？

重复：

【问题讨论】：

应用异或不是“非标准”——它很典型——而且效果不好。
盐很棒。它不仅本身就是一种有用的调味料，而且可以放大菜肴中的其他风味。当然，“太好了”等等，但是……什么？哦，/那个/盐...
@S.Lott，我不是在谈论对密码进行异或并将其保存在数据库中，而是在散列之前进行异或（在散列之前加密密码应该更有效）
散列之前的异或无关，原因与简单异或无关。很容易逆转。 256 次尝试，你就明白了。
所有简单的数学映射都很容易破解。你正在做的事情与做 hash(hash(x)) 一样愚蠢和不安全。

标签： security passwords hash

【解决方案1】：

添加盐并不是为了在前端更难猜测密码，而是为了确保密码的存储不会泄露额外信息。

事实上，盐分是为每个密码随机生成的，并且在没有任何形式的混淆的情况下与密码一起存储。

密码永远不会存储在数据库中，只存储哈希值（MD5、SHA1、SHA2* 等）。

“密码”的 MD5 始终为 286755fad04869ca523320acce0dc6a4。如果您只是将 MD5 存储在密码数据库中，您只需查找该字符串并知道那里的密码是“密码”。

通过添加“84824”盐，总和变为 2ca20e59df3a62e5dc4a3a0037372124。但是如果你有另一个数据库（或另一个用户使用相同的密码），他们可能有一个随机的盐'8999'，给出：4e7a210a07958cfe24138a644cbb7f84

关键是，如果攻击者要获得密码数据库的副本，密码哈希将毫无意义；您甚至无法判断是否有 2 个或更多用户使用相同的密码。

编辑：

相比之下，您应用的数学公式可以颠倒过来。如果选择盐，然后将盐与密码哈希进行异或运算，那么攻击者可以撤消异或操作并获得原始哈希，此时彩虹表非常有用。

如果您认为数学公式无法颠倒，那么您实际上可能会丢失数据，并且您正在将多个密码映射到同一个最终哈希值。这实际上增加了攻击者找到哈希密码的机会，因为任何适当的密码都可以使用。

如果您要进行异或运算并确保异或值的安全，那么这只是一个额外的秘密，需要保存在某个地方，而泄露该秘密实际上会丢失您的所有密码（同样是由于彩虹表）。使用盐没有额外的秘密，操作不能逆转，但可以重复，每个密码都需要单独攻击。

编辑：当然这现在完全相关：I just logged in as you

【讨论】：

这不是没有意义的，现在需要更长的时间，因为现在需要为每种盐制作简单的彩虹表，使其大小呈指数增长。对于 MD5，生成这样的表突然变得不可行（尽管我现在不推荐任何东西，但 SHA-256）。
支持一个关键观察，即每个用户的盐应该不同。这是不明显的，但很重要。
另见：stackoverflow.com/questions/1645161/…
“密码永远不会存储在数据库中，只存储哈希值（MD5、SHA1、SHA2* 等）。” - 可能应该说“密码不应该存储在数据库中......”不幸的是，我已经看到了它们的情况。
“密码”的 md5 实际上是 5f4dcc3b5aa765d61d8327deb882cf99，而不是 286755fad04869ca523320acce0dc6a4。（286755fad04869ca523320acce0dc6a4 是“密码\n”的 md5。:P）

【解决方案2】：

盐与加密哈希一起使用，而不仅仅是添加在密码的前面。您不存储加盐密码或密码，而是存储加盐密码的哈希值。盐的目的是保护用户免受“错误”密码选择的影响，而不是模糊密码。你永远不会只使用盐。

澄清：盐不能防止字典攻击。它可以防止彩虹表式攻击，其中生成一个大的散列表和相应的输入文本。好的密码可以防止猜测（字典攻击），盐有助于防止有人获得您的散列密码，因为使用预先计算的表变得昂贵。当我说“坏”时，我指的是可能存在于现有表格中的密码。

【讨论】：

Salt 不能防止错误的密码选择，除了在输入时检查密码强度之外，没有任何防御措施。（我只是讨厌那些在我的密码中抱怨诸如 . 之类的字符的网站，是的，我说的是我该死的银行……）
我引用“坏”是有原因的，嗯。

【解决方案3】：

你说的没有任何意义。让我们用一个简化的例子来演示。假设您使用的是 MD5，并且攻击者有一个表。该表包括：

john1970->D3 88 99 BC 0C B5 DC 0E D1 7F BB F7 EB F4 EA B2

如果他们随后窃取了您的未加盐数据库并看到哈希 D3...B2，他们就会知道（忽略冲突）密码是 john1970，然后他们可以在您的网站和可能的其他网站上使用该密码。但是，如果您使用盐 123456（显然，随机的会更好），他们将看到一个哈希：

2A CA 76 59 03 23 35 61 E0 20 49 11 8F FE F3 0E

相反。即使他们在获得哈希值时能够破坏盐（您应该尝试通过单独存储它们来防止这种情况发生），他们也会留下：

md5(x+123456) = 2A...0E

而且没有办法轻易确定 x。盐是一种非常强大的技术，应尽可能使用。另一方面，您所谓的“非标准方法”似乎是在发明自己未经证实的散列算法时半途而废的尝试。算了。

【讨论】：

【解决方案4】：

“1-2-3-4-5？这是我这辈子听过的最愚蠢的组合！白痴会在他的行李箱上放那种东西！”

啊太空球……

无论如何，是的，如果您使用 123456 作为您的“盐”，007，安全性可能不会那么好。尽管如此，你还是让消除字典攻击作为破解它的一种手段变得更加困难（除非他们知道盐......）。当然，它仍然可以被蛮力强迫，但诚实的事实是没有什么是不可破解的。你所做的一切都是为了让黑客更难破解，因为不可能破解就是不可能。

【讨论】：

盐应该不保持不变。每个密码应该不同。常量盐将允许对您的帐户列表进行字典攻击（尽管该字典将是您的帐户列表的自定义）。
随机的，或者只是数据库中的一些其他用户数据，比如电子邮件地址等。登录表单中未输入的内容，并且对每个用户都是唯一的。
感谢您的澄清，我并没有试图深入研究它，只是说明误解在哪里......

【解决方案5】：

如果你的盐足够大，创建彩虹表是不切实际的。

http://en.wikipedia.org/wiki/Salt_(cryptography)

这还涉及使用多种因素来加密您的密码。虽然有人可能会窃取您的数据库，但他们可能会遗漏盐，从而成为 SOL。

【讨论】：

【解决方案6】：

“攻击者很可能猜到第一部分是盐。”

真的吗？如何？他们如何知道盐的结束位置和用户提供的密码开始的位置？从密码中解析盐的规则是什么？

你是说它是“显而易见的”，因为盐是数字的吗？然后使用base64盐。现在它有多“明显”？

【讨论】：

假设我们使用了一些随机字符，例如j23$kM2，现在将它添加到一个简单的密码（让我们使用问题中的密码，john1970），现在我们有 j23$kM2 + john1970 = j23$kM2john1970 .. 这还不够明显吗？在散列之前加密密码不会使彩虹字典攻击更难，它会使其无用。
盐的概念不是秘密的，如果一个人有密码哈希，那么他们也会有盐。在大多数情况下，它们都存储在同一张该死的桌子上。不，盐意味着我不能使用预制哈希表（彩虹表），也不能进行 MD5 碰撞攻击。相反，我需要找到一个在加盐后有效的碰撞，即使存在 MD5 中的弱点，这在计算上也是不可行的。

【解决方案7】：

盐的目的不仅仅是混淆密码，而是增加密码的长度。如果黑客不知道盐是什么，他猜测有盐也无济于事。如果盐使密码的长度加倍，这会将可能的单词数提高到二次方。您的 XOR 方法不会这样做。

【讨论】：

通过异或，攻击者将获得一个完全不同的密码..虽然加盐使攻击更加困难，但异或几乎不可能（除非他们知道它是异或）
接受异或的对象必须存储在某个地方......这不再使它更安全。（其实是一种虚假的安全感）
盐也一样
除了散列函数做的第一件事是最终撤消一半的异或......让函数去做那一点。无论如何，盐并不是要保密的，而是添加填充，使彩虹表无用并消除执行碰撞攻击的能力。
“（除非他们知道它是 XORed）” - 通过默默无闻的安全性！= 安全性。

【解决方案8】：

salt 的真正价值不仅在于保护单个记录免受攻击，还在于使多个用户使用相同的密码时，它们的散列形式看起来会有所不同。为使其有效，您必须使用每条记录的盐。

如果您的安全加密/散列机制导致具有相同密码的用户在您的数据库中具有相同的表示，那么您就为攻击者提供了一次破解多个帐户的简单方法。

【讨论】：

【解决方案9】：

盐的设计目的是防御彩虹表，但它的美妙之处在于，知道它是盐绝不会削弱它作为防御措施的作用。这是因为盐并不是有什么神奇的特性或任何东西——而是因为它是添加到攻击者输入的密码中的额外信息，并且特定于他正在攻击的密码——这不是可以重复用于多个帐户 - 甚至不能在同一服务器上使用多个帐户。

当然，攻击者可以将盐添加到他的彩虹表中，但您刚刚使他的彩虹表必须比您用作盐的任何数据更大。

如果添加两个随机字节，攻击者的彩虹表必须是 65536 倍。这不是微不足道的。添加四个随机字节，因子在40亿以上。

【讨论】：

【解决方案10】：

我无法说出问题背后的数学原理，但我将使用一个物理隐喻。只是因为我知道我家门把手上的锁可以用碰撞工具或喷灯来破解，所以我仍然锁上了我的门。我在一栋公寓楼里，还有另一扇门可以进入，我也锁上了那扇门，虽然你可以说那扇门是浪费时间，因为很多人都有钥匙，而且经常把它打开。

安全是一组同心的防御，其中一些比其他的更有趣。这是一个关于哪些防御比利益更有效的判断电话，例如散列 + 盐 + ROT13 可能会增加工作量而不是收益。

【讨论】：

我并不是说加盐没有用，但如果我们谈论的是绝对安全，那么我所说的就是在散列之前加密密码甚至 XORing 更有效。 .
加密并不是更有效，因为它是可逆的......如果一个人可能进入数据库，他们也可能有足够的数据能够从数据库中获取加密密钥。 XOR：这是内置在散列函数中的，xor 是为创建安全散列所做的众多操作之一......应用更多它并没有帮助，实际上它会使事情变得更糟。这就是为什么会有大型竞赛来寻找安全的哈希函数等。
你假设攻击者知道密码在哈希之前是加密的，如果攻击者可以得到加密密钥，那么他们肯定可以得到盐
加密也缺少添加位以确保要散列的字符串足够长以安全地执行此操作。
hmm .. 用一个密钥使用非对称加密怎么样（只生成一个随机密钥，或者如果你有两个密钥丢弃其中一个），这有多可逆？老实说，我认为最好同时使用两者，即在密码中添加盐（足够长的盐），然后如上所述使用非对称加密器加密结果，然后对结果进行散列

【解决方案11】：

加盐确实有很大的不同，但您使用的是哪种哈希算法？请记住，盐总是会添加到该字段中的任何内容中，因此即使发现碰撞，如果他在表单上的该字段中键入它，盐就会被添加并且碰撞不再匹配。

我个人hash(hash(salt1)+hash(pass)+hash(salt2));但是，salt 仅在可以从数据库中获取哈希值时提供保护。如果一个人真的无法获得哈希值，那么最好的方法就是在表单中输入随机的东西。

【讨论】：

很好的解释，但没有理由做这么多哈希。 hash(salt + pass) 如果你改变和存储你的盐就足够了（它应该是每个用户的，而不是整个系统的）。除非您是安全专家，否则采用自己的方法是很危险的。
我这样做的原因是这样可以消除由于哈希长度引起的弱点，确保填充足够。
+ 是连接，而不是位加法或任何类似的东西。
如果您关心哈希长度，使用 2 个长度为 x 的连接哈希远不如使用一个长度为 2x 的哈希安全。如果你的源代码被泄露（它可能发生！），并且他们知道你在做什么 hash64(a) + hash64(b)，彩虹表比 hash128( a+b)。
您应该在设计安全性时假设黑客可以访问您存储的所有内容。使用标准实践很好——我们中很少有人（包括我自己）对安全性有足够的了解来提出可靠的改进。看起来很容易，但安全漏洞会很微妙（如上面的那个）。与大多数错误不同，它不会飞到你面前，直到为时已晚，同时你会有一种虚假的安全感。

【解决方案12】：

安全公理：永远不要在数据库中存储纯文本密码。

考虑到这一点，salt 突然有了很大的不同：因为有了这种 salt，攻击者预先计算的哈希值（前面提到的彩虹表）就没有价值了。

【讨论】：

您阅读了原始问题吗？发布者知道用例。但是询问是否使用 XOR 或数学公式比使用盐字符串预先或后填充密码更好。

【解决方案13】：

由于您提到的原因，它会有所不同：它使使用字典攻击的攻击者的事情变得更加困难。

请查看You Want Salt With That? 以获得很好的解释。

【讨论】：

如果你的链接有另一个页面，那就是它：srp.stanford.edu 也许不是在所有情况下都有用，但阅读起来很有趣。