在客户端使用 bcrypt 进行密码散列的安全性

信息安全 tls 蛮力 bcrypt
2021-08-15 15:28:00

我目前正在使用一种技术,将用户名/密码以明文形式(使用 https)发送到服务器,然后服务器执行 bcrypt 并与数据库进行比较。标准做法。

它被认为是安全的。

将 bcrypt 哈希发送到服务器进行检查是否同样安全?

bcrypt 的关键在于它的计算成本很高,因此被盗的哈希不能被暴力破解(或者需要很长时间)。随着客户端发送哈希,我认为这仍然适用。

所以,问题是,这种技术会以任何方式损害我的网络安全吗?

- 编辑

我想这样做是因为它降低了服务器所需的计算能力。在客户端做中等昂贵的事情从来都不是一个坏主意。

3个回答

问题是您的哈希现在基本上成为您的密码。如果您的哈希数据库被盗,他们不需要担心暴力破解任何哈希,因为这就是您现在需要发送以进行身份​​验证的全部内容。

这篇文章应该回答您的问题:https 安全性 - 密码应该在服务器端还是客户端进行散列?

基本上,如果您在客户端散列,则散列密码将成为身份验证令牌,这意味着您实质上是以纯文本形式将密码存储在数据库中。

所以回答你的问题:它不会危及你的网络安全,但这意味着如果你的数据库被破坏,你首先失去了以散列格式存储密码的所有好处,因为散列现在是密码。

我想现在您已经从答案中知道了为什么将密码哈希发送到服务器可能是一个问题。我只想评论这一点:

我想这样做是因为它降低了服务器所需的计算能力。在客户端做中等昂贵的事情从来都不是一个坏主意。

bcrypt(一种自适应散列函数)速度慢并且消耗更多服务器的计算能力这一事实会使您的服务器容易受到简单的 DoS 攻击。由于这使得密码验证成为一项计算量更大的任务,攻击者可以向服务器发送许多登录请求,并诱使服务器完成比预期更多的工作。您可以在以下线程中找到有关该问题的更多详细信息:

客户端散列可以降低慢速散列的拒绝服务风险吗?

如果您的服务器使用 bcrypt,您是否应该关心 DoS 攻击?

因此,您可以使用工作量证明方案,而不是在客户端对密码进行哈希处理,您的浏览器执行大量计算并向服务器提供证明,证明服务器可以在同一个请求中快速验证密码已提交。这样,服务器将仅在验证 PoW 时计算 bcrypt。这可以防止服务器 DoS,因为客户端也必须做一些工作。对于计算能力较低的设备(可能不适合计算工作量证明),可以使用 CAPTCHA 等方案。