如何保护身份验证而不是有效负载？
我正在寻找现有的 HTTP 协议来保护身份验证，但不是随后的有效负载。 我希望服务器存储每个用户的用户名、散列密码和不同的盐。
HTTP 摘要式身份验证未满足这些要求，因为所有帐户都使用相同的盐。 SSL 失败是因为它加密了整个连接。
编辑添加：
这是用于与网络服务通信的桌面客户端（不涉及浏览器）
I'm looking for an existing HTTP protocol for securing authentication but not the payload that follows. I want the server to store the username, hashed password and different salt per user.
HTTP Digest Authentication fails these requirements because all accounts use the same salt. SSL fails because it encrypts the entire connection.
Edited to add:
This is for a desktop client talking to a web service (no browser involved)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
流行的方案是使用 SSL 保护登录表单，而网站的其余部分不使用 SSL。 例如，参见流行的社交网站。
The popular scheme is to have login form protected by SSL, while rest of the site doesn't use SSL. See for example popular social networking sites.
为什么不直接让您的身份验证机制受 SSL 保护，然后转发到在正常 HTTP 下运行的应用程序的其余部分？
Why not just have your authentication mechanism protected by SSL and then forward to the rest of your application which runs under normal HTTP?
OpenID 怎么样？ 您是否有必须存储身份验证信息的原因？
编辑添加
抱歉没有发现它是一个桌面应用程序。 OAuth 怎么样？
How about OpenID? Is there a reason that you have to store authentication information?
Edited to add
Sorry didn't catch that it was a desktop app. How about OAuth?
有没有一种方法可以构建原始请求 URL 来指示用户？ 然后，服务器可以在 HTTP 摘要身份验证响应中为每个用户使用不同的领域（充当“盐”）进行响应。 例如，
http://user.y.com/service或http://www.y.com/user/service形式的请求 URL 将导致诸如以下的挑战回应：您能解释一下是什么推动了“不加密”的要求吗？ 如果您受到中间人攻击，则需要保护整个请求的完整性。 在那里，SSL 会非常有帮助。 如果您绝对无法进行加密，那么使用未加密的密码套件的 SSL 可以接受吗？
Is there a way that you could structure the original request URL to indicate the user? Then, the server could respond with a different different realm (acting as "salt") for every user in the HTTP digest authentication response. For example, request URLs of the form
http://user.y.com/serviceorhttp://www.y.com/user/servicewould result in a challenge response like:Can you explain what's driving the "no encryption" mandate? If you are subject to man-in-the-middle attacks, you need to protect the integrity of the entire request. There, SSL would be very helpful. If you absolutely cannot have encryption, would SSL using an unencrypted cipher suite be acceptable?