hash - 对 Web 服务的密码加盐的原因

标签 hash passwords salt

我有一个与用户管理相关的非常基本的问题,特别是存储哈希密码。 我读了几页(例如 https://wiki.python.org/moin/Md5Passwords )。 我理解哈希的方式是这样的:

  • 用户提供的密码以一种方式进行哈希处理(使用任何函数)。
  • 任何人(包括用户/管理员)都无法看到密码。
  • 当用户登录时 - 对他提供的字符串进行哈希处理,以查看其是否与存储的哈希密码匹配。

这一切都很清楚,但是我不确定散列中的“盐”是什么。 我读到 os.urandom (Python) 很适合创建好的盐: https://crackstation.net/hashing-security.htm

我不确定如何使用这种添加的“盐” 如果我用盐散列用户密码及其一种方式。下次用户登录时,他只知道密码而不知道盐。由此我假设为该用户生成的“盐”需要存储在某个地方。否则就没有意义。但另一方面,如果有人访问数据库,则会看到“盐”和散列密码。在这种情况下,“盐”不会增加太多值(value)(它与散列纯密码几乎相同)。所以也许“盐”只是为了防止前端的保护(防止暴力)。

有人可以告诉我如何使用盐吗?我的理解是否正确。我需要在某处存储“盐”吗?

在我发布这个问题之前,我发现了这个: Should the Salt for a password Hash be "hashed" also?

盐的附加值是多少? 如果我编写 Web 服务,我可以在 3 次失败尝试后阻止每次登录。 前端没有人能够看到哈希值。没有人可以使用暴力破解(这可能只是 DoS,因为 3 次登录失败将阻止用户)。黑客需要访问数据库并查看散列密码。但如果他有,他就会看到“盐”。

最佳答案

盐用于防止黑客将密码哈希值逆向为密码。所以这里我们假设黑客以某种方式访问​​了数据库。

不加盐

让我们首先假设没有盐的场景。在这种情况下,表格如下所示:

user | md5 password (first 6 chars)
-------------------------------
   1 | 1932ff
   2 | d3b073

(我们在这里使情况比实际情况更简单)

黑客当然想知道d3b0731932ff背后的密码是什么。哈希函数是单向,因为我们可以非常快地对密码进行哈希处理,但是在猜测大量密码后,如果它是一个很好的哈希函数,则对其进行取消哈希处理会花费很长时间密码。

因此,轻松检索 d3b073 背后可能的密码的希望不大。但我们可以轻松找到 100'000 个最流行密码的列表,并计算所有这些密码的 MD5 哈希值。这样的列表可能如下所示:

password | md5 (first 6 characters)
--------------------------------------------
foo      | d3b073
bar      | c157a7

显然用户2已使用foo作为密码。我们不知道用户 1 的密码(但我们知道它不是 foobar)。

现在的重点是,我们可以构建这样的表一次,然后用它来破解所有用户的所有密码。为 100'000 个密码构建这样的表可能需要几个小时,但随后我们可以轻松检索所有密码。因此,黑客可以构建(或下载)这样的表(有更有效的方法,例如使用彩虹表),然后在每次攻击网站时使用它,然后获取密码所有用户。

加盐

如果我们使用加盐,表格可能如下所示:

user | salt   | hashed password
-------------------------------
   1 | a91f40 | 1a604e
   2 | c2a67c | b36232

所以这里如果用户2的密码是foo,那么我们计算fooc2a67c的哈希值(或者我们使用另一种方式组合盐和密码)并将其存储到数据库中。

重点是,很难猜出密码,因为 b36232 不是 foo 的哈希值,而是 fooc2a67c 的哈希值,并且盐通常是(伪)随机的。我们当然可以再次构建最流行的 100,000 个密码,并附加盐 c2a67c,但由于我们无法提前知道,因此我们无法创建这个仅表一次。即使我们很幸运并且已经构建了 salt c2a67c 表,它也无法帮助我们破解用户 1 的密码,因为用户 1 有不同的 salt。

所以解决这个问题的唯一方法是为每个用户构建一个反向哈希查找表。由于构建一次这样的表通常非常昂贵,因此为每个用户计算这样的表并不容易。

我们当然可能决定计算所有可能盐的所有哈希值,例如:

password  | md5 (first 6 characters)
---------------------------------------------
foo000000 | 367390
foo000001 | eca8ea
foo000002 | 6eb7bf
foo000003 | 7906b1
foo000004 | 0e9f0c
foo000005 | 0bfb11
...       | ...

但是正如您所看到的,这样的表的大小将增长到巨大。而且还需要数千年的时间。即使我们只添加一个十六进制字符作为盐,表的大小也会缩放 16 倍。是的,有一些技术可以减少此类表的时间和空间量,但是通过增加“密码空间”,破解密码的问题肯定会更加困难。此外,salt 通常包含大量字符(或字节),这使得它比仅仅 16 倍更困难。

盐基本上是一种扩大密码空间的方法。即使您在两个网站上输入完全相同的密码,网站的个人盐也将(接近确定性)是唯一的,因此哈希值也将是唯一的。

关于hash - 对 Web 服务的密码加盐的原因,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48095788/

相关文章:

url - 带哈希部分( anchor )的重定向 301 #

Jquery 哈希导航

linux - ecryptfs - passwd 实用程序如何更新非管理员密码更改的哈希值?

security - 最佳密码盐长度

c++ - boost c++ unordered_map 使用的是什么哈希函数?

c# - 如何在 C# 中使用 BouncyCaSTLe 进行 Blowfish 单向哈希?

ios - PayPal iOS 模拟器应用程序接受无效密码

c# - Rfc2898DeriveBytes (PBKDF2) 实现中 key 大小的重要性

PHP crypt 和 salt - 请详细说明

hash - 如果密码是saltedhash,如何恢复用户忘记的密码?