【问题标题】:Using a hash of what you are hashing as a salt?使用您正在散列的散列作为盐的散列?
【发布时间】:2009-07-13 16:03:03
【问题描述】:

假设用户注册了您的网站,您对他们选择的密码进行哈希处理,然后将该哈希用作盐,并使用该盐重新对他们的密码进行哈希处理。

例子:

String hash1 = MD5(password);
String endHash = MD5(hash1 + password);

然后将 endHash 存储在您的数据库中。如果我的数据库遭到破坏,这是否能有效抵御 Rainbow Table 攻击?还是我错过了一些容易破坏的东西?

【问题讨论】:

  • 这应该是处理安全协议的第一条规则:不要试图变得聪明,你只会破坏它。使用随机盐。不是用户名。不是任何东西的哈希。只是随机数据。

标签: database security hash


【解决方案1】:

这是关键强化 (http://en.wikipedia.org/wiki/Key_strengthening),一种很好的技术,但不能替代实际的盐。它不会保护您免受使用此双哈希函数编写的彩虹表的影响。

【讨论】:

    【解决方案2】:

    加盐的目的是防止使用巨大的预先计算好的表格。使用这种方法可以计算任何密码的哈希值,而无需访问您的数据库。您应该存储一个随机值并将密码和该值一起散列。

    【讨论】:

      【解决方案3】:

      散列密码的弱点在于攻击者对您的散列函数的了解。如果他们知道您的哈希函数但不知道您的盐,则盐保护了您的密码。如果他们知道哈希函数和你的盐,你的数据就有风险。

      因为这适用于您的问题 - 使用动态盐通常会使您更难以计算出您的盐。这提高了安全性,但如果有人知道您的算法,则无济于事。

      以这种方式增加您的复杂性确实会使您的系统更难破解。然而,只要有足够的资源,没有什么是不可破解的。

      【讨论】:

      • 盐可以完全公开,而不会影响您选择的密码方案的安全性。 salt的主要工作是防止使用预先生成的彩虹表,而不是防止为每个密码生成新的自定义彩虹表。
      【解决方案4】:

      您应该使用用户名作为函数的盐,而不是两次散列:

      String hash = MD5(username + password)
      

      您还应该考虑使用不同的函数,因为 md5 被认为是损坏的 MD5

      【讨论】:

        【解决方案5】:

        没什么区别:您存储的数据仍然完全基于密码,因此没有额外的保护。

        【讨论】:

        • 还有一些额外的保护,因为约定彩虹表会失败,而自定义彩虹表的生成时间会增加一倍。但是,当然,你没有像盐那样保护它是对的。
        【解决方案6】:

        此外,您应该避免使用 MD5,而使用当前强大的哈希算法,例如 SHA1、SHA-256、SHA-512。

        【讨论】:

        • 是的,我正打算使用 MD5 作为示例,因为它是最广为人知的。
        猜你喜欢
        • 1970-01-01
        • 2016-09-04
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-05-16
        • 1970-01-01
        • 2013-03-15
        相关资源
        最近更新 更多