通过 HTTPS 进行客户端哈希/加盐
我想知道以下设置的严重问题是什么：
用户名/密码登录方案 Javascript/ajax 从服务器请求盐值（我们在前面的问题中已经确定盐不是秘密值） Javascript 对密码和盐执行 SHA1（或其他方式）。 Javascript/ajax 将哈希值返回到服务器 服务器在通过 ajax 发送的盐/哈希之上应用另一个盐/哈希。
交易通过 HTTPS 进行。
我担心可能存在的问题，但无法说服自己这是一个糟糕的设置。假设所有用户都需要启用 javascript，因为该网站大量使用 jQuery。它基本上是尝试为密码的纯文本添加额外的安全层。
I'm wondering what the serious issues are with the following setup:
Username/password login scheme
Javascript/ajax requests the salt value from the server (we have established in previous questions salt is not a secret value)
Javascript preforms an SHA1 (or otherwise) of the password and salt.
Javascript/ajax return the hash to the server
The server applies another salt/hash on-top of the the one sent via ajax.
Transactions are over HTTPS.
I'm concerned about problems that may exist but can't convince myself that this is that bad of a setup. Assume that all users need javascript enabled as jQuery is heavily used on the site. It's basically attempting to add an additional layer of security to the plain-text of a password.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一如既往：自己设计加密协议时要非常小心。
但话虽这么说，我可以看到该方案的优势。它将防止密码通过中间人攻击而泄露，并且它将确保服务器永远不会看到实际密码，从而防止某些内部攻击攻击。另一方面，它不能防止浏览器中的人攻击、钓鱼等。
您可能需要通读 RFC 2617 关于 HTTP 摘要访问身份验证。该方案与您提出的方案类似。
As always: be very careful about designing cryptographic protocols yourself.
But that being said, I can see the advantage in the scheme. It will protect against the password being revealed through a man-in-the-middle-attack and it will ensure that the server never sees the actual password, thus preventing some inside attacks. On the other hand it does not protect against man-in-the-browser, fishing etc.
You might want to read through RFC 2617 about HTTP Digest access authentication. That scheme is similar to what you propose.
在客户端和服务器之间传递盐和哈希值的所有工作都已内置到底层 HTTPS/SSL 协议中。如果 javascript 中的安全层能够提供很大帮助，我会感到非常惊讶。我建议保持简单并在客户端使用基于 SSL 的纯文本。担心服务器端的加密。
All that effort of passing salts and hashes between the client and server is already built into the underlying HTTPS/SSL protocol. I would be very surprised if a security layer in javascript is going to help very much. I recommend keeping it simple and use plaintext over SSL on the client-side. Worry about encryption on the server-side.
我将 100% 不同意已接受的答案，并表示在任何情况下都不应将原始密码留给客户端。它应该总是加盐和散列。总是如此，无一例外。
两个原因...
。客户端不应依赖所有服务器组件和内部网络都是 TSL。 TSL 端点作为负载平衡反向代理是很常见的，它使用明文与应用程序服务器进行通信，因为 devops 不会费心为所有内部服务器生成服务器证书。
。许多用户病态地倾向于对所有服务使用通用密码。服务器具有明文密码（即使仅在内存中）这一事实使其成为外部攻击的有吸引力的目标。
I'll 100% disagree with the accepted answer and say that under no circumstances should an original password ever Ever EVER leave the client. It should always be salted and hashed. Always, without exception.
Two reasons...
. The client should not be relying that all the server components and internal networks are TSL. It is quite common for the TSL endpoint to be a load balancing reverse proxy, which communicates with app servers using plaintext because devops can't be bothered to generate server certs for all their internal servers.
. Many users are pathologically inclined to use a common password for all of their services. The fact that a server has plaintext passwords, even if only in memory, makes it an attractive target for external attack.
这不会增加任何额外的安全性。 JavaScript 代码存在于客户端中，因此哈希算法是已知的。在这种情况下，执行客户端哈希不会获得任何好处。
此外，客户端没有理由应该了解哈希盐。它实际上应该是一个秘密值，特别是当您使用共享盐时。
This doesn't add any additional security. The JavaScript code is present in the client, so the hashing algorithm is known. You gain nothing from doing a client-side hash in this case.
Also, there's no reason why the client should know about the hashing salt. It actually should be a secret value, especially if you're using a shared salt.
你没有得到任何东西。如果 Joe Public 可以通过单击“查看”>“查看”来看到盐，那么盐就没有意义了。来源，以及关于从不信任客户端输入的古老格言对于密码散列来说是双重的。
如果您确实想提高安全性，请使用基于 SHA-2 的哈希 (SHA-224/256/384/512)，因为 SHA-1 具有潜在的漏洞。 NIST 不再建议将 SHA-1 用于易受冲突攻击（例如密码哈希）的应用程序。
You're not gaining anything. There's no point to a salt if Joe Public can see it by clicking View > Source, and the old maxim about never trusting client input goes double for password hashing.
If you really want to increase security, use a SHA-2 based hash (SHA-224/256/384/512), as SHA-1 has potential vulnerabilities. NIST no longer recommends SHA-1 for applications that are vulnerable to collision attacks (like password hashes).