您所描述的并没有提高系统的安全性。这不是意见或情感的问题，安全只是不能那样工作。在您的示例中，hash(salt+password)现在是您的密码。如果不是通过 https，那么攻击者可以重放该值。此外，您并没有真正解决owasp a9又名“firesheep”风格的攻击。

它与您要保护的一般范围有关。如果您正在开发服务器端应用程序，那么您正在尝试保护服务器免受用户及其客户端系统的影响。让用户系统（即客户端）为您完成安全工作并不能真正帮助服务器保持受保护状态。通常假设客户端在做某事时，即使它按照服务器的要求工作（就服务器交付的 JavaScript 而言），客户端天生就是不受信任的，因为黑客可以控制客户端应用程序并提交与 JavaScript 分开的输入。

服务器对密码进行哈希处理以抑制因密码存储泄露而导致的问题。如果攻击者掌握了密码哈希，则应该不可能通过从被黑客户端发送密码来使用它们——因为服务器正在做自己的哈希。 如果服务器将这项工作委托给客户端，那么服务器也委托了一项安全功能。

这一切都取决于您如何定义保护边界。如果您有理由相信客户端计算机绝对没有威胁，并且客户端系统永远不会被黑客入侵，那么这个问题就会消失......但我不知道有任何网络系统可以肯定地提出这个要求.

核心原因不是仇恨……而是不安全感。一个普遍的原则是不要相信任何你无法控制的东西。在用户对应用程序进行身份验证的情况下，除非您向用户提供笔记本电脑、配置其控件以及其所在环境的控件，否则您不能信任它。

传统的看待它的方式是，如果攻击者可以物理访问计算机，他们就可以为所欲为。

使用仅设置加密链接的简单浏览器，几乎不会受到损害，使用较厚的客户端，客户端的任何功能都可能受到损害。

如果您在客户端计算哈希，则增加了攻击者只需要用户密码的哈希而不是实际密码即可登录的风险。您可能可以通过发送一个随机数来使用（基本上是每个会话的盐）对密码进行哈希处理来解决这个问题，但是您仍然必须在服务器端对其进行哈希处理，所以为什么还要在客户端上这样做呢?