【问题标题】:SHA1 not secure? [duplicate]SHA1 不安全? [复制]
【发布时间】:2012-06-16 01:55:41
【问题描述】:

可能重复:
Is SHA-1 secure for password storage?

我是加密新手,我有一个疑问。这可能是一个愚蠢的问题,但我要问。我知道 SHA1 不能解密。但快速思考一下,如果黑客创建一个包含两列的表 - 非加密密码及其 SHA1 加密值。这些行包含他在 6 个月内使用程序生成的所有字符组合的密码(比如 9 亿条记录)。如果他得到了SHA1加密密码,他就不能轻易得到非加密密码吗?

如果是,有什么办法可以防止这种情况发生吗?

提前致谢。

【问题讨论】:

  • 你的 9 亿条记录的价值从何而来?例如,8 个字母或数字的密码给出 2.18*10^14 种可能性。
  • 别当真:D我只是用它来说明黑客在他的数据库中拥有所有密码组合。
  • 您指的是rainbow table。除此之外,这个问题是重复的。

标签: sha1


【解决方案1】:

您描述的攻击称为rainbow table。是的,这对于短密码当然是一个有效的考虑——因此是对密码最小长度的典型安全要求。但是,表的大小需要随着密码的长度呈指数增长;例如,字母数字区分大小写的密码每增加一个字符,表就会增加 62 倍。因此,计算超过一定长度变得棘手。 (仅 8 个字符就可以产生大约 218 个 trillion 组合。)

您可以采取的另一项预防措施是salt 您的密码(这可能简单地涉及在计算其哈希值之前将一个常量字符串附加到每个密码)。这样,即使攻击者可以访问预先计算的彩虹表,它对你的哈希也没有用;必须为每种盐计算一个新的彩虹表。

【讨论】:

    【解决方案2】:

    防止彩虹表攻击的常见解决方案是使用Salt

    不过,我要补充一点,SHA1 并不被认为是非常安全的。使用功能强大的计算机,使用蛮力查找未加密的密码非常容易。对于存储密码,建议使用 bcrypt 或 PBKDF2 等慢速哈希算法。

    【讨论】:

      【解决方案3】:

      是的。这就是为什么给你的哈希加盐很重要。只要您的已正确加盐,您所说的表格类型仅对单个密码有用。

      例如见http://msdn.microsoft.com/en-us/magazine/cc164107.aspx

      【讨论】:

        【解决方案4】:

        可以通过对哈希进行加盐来防止字典攻击,例如您所描述的攻击。从本质上讲,您强制明文的长度和复杂性超出了所使用的字典的范围。

        实现起来也很简单。一种方法是维护一个密码,例如“0shunF1ave”并将其附加到您的明文中。因此,您可以存储 SHA1("0shunF1ave"+password),而不是存储 SHA1(密码)。当您验证密码时,您对候选人执行相同的哈希,例如 SHA1("0shunF1av1"+candidate) 到您最初存储的哈希,看看它们是否匹配。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2011-02-26
          • 1970-01-01
          • 2013-05-18
          • 1970-01-01
          • 2011-10-10
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多