【问题标题】:Why can't we store every hashed password ever in storage(HDD) and use that to match the hashed password instead of use brute force password cracking?为什么我们不能将每个散列密码存储在存储(HDD)中并使用它来匹配散列密码而不是使用暴力破解密码?
【发布时间】:2020-12-16 10:52:53
【问题描述】:

假设我们以某种方式获得了受害者的哈希密码。

因此,蛮力方法是获取每个可能的字符串,对其进行哈希处理并检查它是否与受害者的哈希密码匹配。如果是这样,我们可以使用该字符串作为密码并因此被黑客入侵。

但这需要大量的计算能力和大量的时间,即使对于 6-8 个字符的字符串也是如此。

但是,如果我们可以散列所有少于 10(一些)字符的可能字符串,并事先将其存储在存储中,就像一个已排序的数据库一样。这样当你得到哈希密码时,你可以很容易地查表并得到密码。

附注:-
对于这个例子,假设我们只使用一种类型的散列算法,并且有巨大的数据服务器来存储数据。 我是安全新手,这是一个非常基本的问题,但由于某种原因,这个问题的答案在互联网上真的很难找到。

【问题讨论】:

    标签: security hash passwords storage brute-force


    【解决方案1】:

    这被称为rainbow table,是一个众所周知的概念。

    这也是你永远不应该只存储密码哈希的原因。 salt(添加到密码中的随机字符串,然后与哈希一起存储为明文进行验证)可以通过有效地使彩虹表无法使用并强制重新计算来轻松缓解这种攻击。

    还只是为了完整性,重要的是要注意纯加密哈希不再足以用于凭据(密码),因为它们太快了,这意味着为给定的盐生成彩虹表太快了,有效暴力破解密码。如果仅使用普通加密哈希进行哈希处理,即使使用盐,专用硬件也可以恢复相对强的密码。

    因此,最好的做法是使用key derivation function (KDF) 生成密码哈希,这种方式使得暴力破解速度非常慢(不可行),但速度足以验证。同样在大多数已知的实现中,向每个哈希添加随机盐是自动的,并且整个事情都是安全的。

    例如 PBKDF2、bcrypt、scrypt 或最近的 Argon2 等算法。它们中的每一个都有不同的特性,并且对不同的攻击具有更强的抵抗力。

    【讨论】:

      猜你喜欢
      • 2013-07-25
      • 2019-02-11
      • 2011-01-20
      • 2011-09-14
      • 1970-01-01
      • 2011-09-28
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多