应用错误收集

我读过这些：

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

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

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

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

此外，如果密码已经哈希，我认为服务器端没有任何理由对其进行哈希处理。如果您的服务器被破解，您就完成了 - 无论密码如何 - 但是破解者无法在其他任何地方使用获取的密码。

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

如果您认为哈希客户端和服务器端与现代密码散列算法像PBKDF2，BCrypt，SCrypt，或Argon2高工作因子/迭代次数比较好，那么我同意。

如果您认为哈希只是客户端更好，那么我对您的威胁模型有严重保留。

存在威胁，服务器端的哈希密码可以防范，客户端可以防御的威胁;这里有一个简短的清单：

BOTH：泄露密码数据库条目，允许查看者查看用户以明文形式输入的内容。
客户端：服务器端内部人员使用数据包/流量拦截访问来查看用户直接输入的内容
- 这是客户端散列加入服务器端哈希的两个主要威胁之一，非常适合缓解。
服务器：具有数据库访问权限的内部人员欺骗性地冒充实际用户
- 如果密码只是哈希客户端，那么服务器数据库中的任何内容都可以通过客户端请求提供给系统，以用户身份登录＃34;合法地＆＃34;根据服务器。这使得所有服务器审计日志中的人都做了可疑的事情。
- 如果密码是服务器端的哈希值，无论客户端发生了什么，服务器中的内容都不会通过正常的身份验证通道对用户进行身份验证。
客户端：MitM攻击查看用户实际输入的内容
- 这是客户端散列加入服务器端哈希的其他主要威胁，非常适合缓解。
- MitM攻击可以来自客户的公司IT部门，网络提供商或其他ISP，服务器组织的IT部门（负载均衡器或具有实际证书密钥的高级安全设备等）或许多其他来源。
NEITHER：MitM攻击者欺骗性地冒充实际用户
- 无论您是否将客户端哈希，通过网络发送到服务器应用程序的内容都是服务器用来验证您身份的内容。