security - 我仍然认为在客户端散列密码更好。我错了吗？

Question

我读过这些:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side

Is it worth hashing passwords on the client side

Password encryption at client side

https://softwareengineering.stackexchange.com/questions/76939/why-almost-no-webpages-hash-passwords-in-the-client-before-submitting-and-hashi

...而且我仍然认为在客户端散列密码更好。让我解释一下。

引用的第一篇文章主张您应该使登录页面独立，因为没有办法信任客户端使用的整个代码库。我认为这是有道理的。

如果有道理，您如何信任服务器端使用的整个代码库？

上面很多赞成的答案都声称“不要在客户端散列，因为 TLS 存在”。这对于防止密码被嗅探是正确的，但如果它与我们潜在的恶意服务器端代码有关，则根本不相关。

此外，如果密码已经经过哈希处理，我看不出有任何理由让服务器端对密码进行哈希处理。如果您的服务器被破解，那么您就完蛋了 - 不管密码如何 - 但破解者无法在其他任何地方使用获得的密码。

但由于我找不到这样的答案，我的说法似乎从根本上是错误的。我错过了什么？

Answer 1

如果您认为使用 PBKDF2、BCrypt、SCrypt 或 Argon2 等具有高工作因子/迭代计数的现代密码哈希算法对客户端和服务器端进行哈希处理更好，那么我同意。

如果您认为仅客户端散列更好，那么我对您的威胁模型持严重保留意见。

有散列密码服务器端防范的威胁和客户端防范的威胁；这是一个简短的列表:

• 两者:密码数据库条目泄露，允许查看者以明文形式查看用户输入的内容。
• 客户端:具有数据包/流量拦截访问权限的服务器端内部人员可以看到用户直接输入的内容
  • 这是客户端散列和服务器端散列非常适合缓解的两大威胁之一。
• 服务器:具有数据库访问权限的内部人员伪装成实际用户
  • 如果密码仅在客户端进行哈希处理，那么服务器数据库中的任何内容都可以通过客户端请求提供给系统，以根据服务器“合法地”以用户身份登录。这使得所有关于谁做了什么的服务器审计日志都变得可疑。
  • 如果密码在服务器端经过哈希处理，无论客户端发生了什么，如果通过正常身份验证 channel 输入，服务器中的内容不会对用户进行身份验证。
• 客户端:MitM 攻击查看用户实际输入的内容
  • 这是除了服务器端哈希之外客户端哈希非常适合缓解的其他主要威胁。
  • MitM 攻击可能来自客户的公司 IT 部门、网络提供商或其他 ISP、服务器组织的 IT 部门(负载平衡器或具有实际证书 key 的高级安全设备等)或许多其他来源。<
• 都不是:MitM 攻击者伪装成实际用户
  • 无论您是否在客户端对其进行哈希处理，通过网络发送到服务器应用程序的内容都是服务器用来对您进行身份验证的内容。