为什么我们不能将每个散列密码存储在存储（HDD）中并使用它来匹配散列密码而不是使用暴力破解密码？
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?
假设我们以某种方式获得了受害者的哈希密码。
所以蛮力方法是获取每个可能的字符串，对其进行哈希处理并检查它是否与受害者的哈希密码相匹配。如果确实如此，我们可以使用该字符串作为密码并因此被破解。
但这需要大量的计算能力和大量的时间，即使对于具有 6-8 个字符的字符串也是如此。
但是，如果我们可以对每个可能的少于 10（一些）字符的字符串进行哈希处理，并将其存储在存储中，就像预先排序的数据库一样。这样当您获得散列密码时，您可以轻松查找 table 并获取密码。
P.S:-
对于这个例子，假设我们只使用一种类型的哈希算法，并且有巨大的数据服务器来存储数据。
我是安全新手，这是一个非常非常基本的问题，但出于某种原因，这个问题的答案真的很难在互联网上找到。
这称为 rainbow table，这是一个众所周知的概念。
这也是您永远不应该只存储密码哈希值的原因。 salt（添加到密码中的随机字符串，然后与哈希一起存储为明文以进行验证）可以通过有效地使彩虹 table 无法使用并强制重新计算来轻松缓解这种攻击。
另外，为了完整起见，重要的是要注意纯加密哈希不再适合用于凭据（密码），因为它们太快了，这意味着生成彩虹太快了table对于给定的盐，有效地暴力破解密码。如果仅使用普通加密散列进行散列，即使使用盐，专用硬件也可以恢复相对强的密码。
因此，最佳做法是使用 key derivation function (KDF) 生成您的密码哈希，其方式使暴力破解变得非常缓慢（不可行），但速度足以验证。同样在大多数已知的实现中，向每个哈希添加随机盐是自动的，并且整个过程都是安全的。
例如 PBKDF2、bcrypt、scrypt 或最近的 Argon2 等算法。它们各自具有不同的特性，并且更能抵抗不同的攻击。
假设我们以某种方式获得了受害者的哈希密码。
所以蛮力方法是获取每个可能的字符串，对其进行哈希处理并检查它是否与受害者的哈希密码相匹配。如果确实如此，我们可以使用该字符串作为密码并因此被破解。
但这需要大量的计算能力和大量的时间，即使对于具有 6-8 个字符的字符串也是如此。
但是，如果我们可以对每个可能的少于 10（一些）字符的字符串进行哈希处理，并将其存储在存储中，就像预先排序的数据库一样。这样当您获得散列密码时，您可以轻松查找 table 并获取密码。
P.S:-
对于这个例子，假设我们只使用一种类型的哈希算法，并且有巨大的数据服务器来存储数据。
我是安全新手，这是一个非常非常基本的问题，但出于某种原因，这个问题的答案真的很难在互联网上找到。
这称为 rainbow table，这是一个众所周知的概念。
这也是您永远不应该只存储密码哈希值的原因。 salt（添加到密码中的随机字符串，然后与哈希一起存储为明文以进行验证）可以通过有效地使彩虹 table 无法使用并强制重新计算来轻松缓解这种攻击。
另外，为了完整起见，重要的是要注意纯加密哈希不再适合用于凭据（密码），因为它们太快了，这意味着生成彩虹太快了table对于给定的盐，有效地暴力破解密码。如果仅使用普通加密散列进行散列，即使使用盐，专用硬件也可以恢复相对强的密码。
因此，最佳做法是使用 key derivation function (KDF) 生成您的密码哈希，其方式使暴力破解变得非常缓慢（不可行），但速度足以验证。同样在大多数已知的实现中，向每个哈希添加随机盐是自动的，并且整个过程都是安全的。
例如 PBKDF2、bcrypt、scrypt 或最近的 Argon2 等算法。它们各自具有不同的特性，并且更能抵抗不同的攻击。