HTTP 摘要式身份验证
我想将 HTTP 摘要身份验证与存储用户名和加密密码的中央数据库结合使用。这些数据应该由不同的服务器使用，例如 Apache httpd 或 Tomcat。客户端将是使用浏览器和其他应用程序以 RESTful 方式进行通信的人类。
据我了解，我无法使用带有哈希密码的表。只能在明确的位置存储 HA1 = MD5(username:realm:password)需要文本密码 - 正确吗？
另一方面，似乎可以在 Apache httpd 中使用哈希密码：
第一个的第一列值 查询语句返回的行 应该是一个包含 加密密码。
它可以与摘要身份验证一起使用吗？没有参数来指定哈希算法。 Apache httpd 如何决定使用哪种算法？
RFC 2617 说：
4.13 存储密码
摘要式身份验证要求 验证代理（通常 服务器）存储一些派生的数据 从用户名和密码 在与关联的“密码文件”中 给定境界。通常这可能 包含由用户名组成的对 和 H(A1)，其中 H(A1) 是 用户名、领域的消化值， 和密码如上所述。
听起来密码必须是明文。
Servlet 3.0 规范说：
虽然密码没有发送到 有线、HTTP 摘要式身份验证 需要明文密码 等价物可用于 验证容器，以便它 可以验证收到的验证器 通过计算预期摘要。
这里的“等效明文密码”是什么？密码哈希？
Tomcat 文档 说：
如果使用摘要密码 DIGEST 身份验证，明文 用于生成摘要的是 不同的。在上面的例子中 必须替换 {cleartext-password} 和 {用户名}：{领域}：{明文密码}。 例如，在一个开发中 环境这可能采取以下形式 testUser:localhost:8080:testPassword。
这里需要一个明文密码。
那么，HTTP Digest 身份验证是否可以与已加密的密码一起使用，还是可以将密码设置为明文？
如果用户从不同的子域请求页面，是否必须重新输入其凭据？
浏览器是在选项卡关闭时删除缓存的密码还是仅在整个关闭时删除？也许这因浏览器而异 - 我感兴趣的是哪个浏览器删除它以及哪个浏览器保留它。
总体问题是，摘要身份验证是否适合我的使用已加密密码的中央用户数据库的场景。或者我应该更好地使用基于会话的单点登录服务？
I want to use HTTP Digest Authentication with a central database that stores usernames and encrypted passwords. These data should be used by different servers like Apache httpd or Tomcat for example. The clients will be humans with browsers and other applications communicating in a RESTful way.
As far as I understand I could not use a table with hashed passwords. It is only possibly to store HA1 = MD5(username:realm:password) where a clear text password is required - correct?
On the other hand it seems to be possible to use hashed passwords with Apache httpd:
Apache httpd doc says:
The first column value of the first
row returned by the query statement
should be a string containing the
encrypted password.
Does it work with digest authentication? There is no parameter to specify the hash algorithm. How does Apache httpd decide which algorithm to use?
RFC 2617 says:
4.13 Storing passwords
Digest authentication requires that
the authenticating agent (usually
the server) store some data derived
from the user's name and password
in a "password file" associated with a
given realm. Normally this might
contain pairs consisting of username
and H(A1), where H(A1) is the
digested value of the username, realm,
and password as described above.
It sounds like the password has to be clear text.
The Servlet 3.0 spec says:
Although passwords are not sent on the
wire, HTTP Digest authentication
requires that clear text password
equivalents be avaialble to the
authenticating container so that it
can validate received authenticators
by calculating the expected digest.
What is the "clear text password equivalent" here? The password hash?
Tomcat documentation says:
If using digested passwords with
DIGEST authentication, the cleartext
used to generate the digest is
different. In the examples above
{cleartext-password} must be replaced
with
{username}:{realm}:{cleartext-password}.
For example, in a development
environment this might take the form
testUser:localhost:8080:testPassword.
Here is a clear text password required.
So, can HTTP Digest authentication be used with already encrypted passwords or have the passwords to be clear text?
Must the user re-enter his credentials if he requests a page from a different subdomain?
Does the browser delete the cached password when the tab is closed or only when the whole is closed? Maybe this differs from browser to browser - I'd be interested in which browser delete it and which keep it.
The overall question is, whether digest authentication is suitable for my scenario with a central user db with already encrypted passwords. Or should I better use session based single sign on service?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这种情况下，如果您已经拥有散列密码的数据库，则不可能使用摘要身份验证，因为它们没有使用相同的函数进行散列。
我认为最适合您的解决方案是创建一个登录页面并使用 cookie 会话来控制用户的权限。通过此解决方案，您可以获得其他问题的答案：
In this scenario where you have already a database of hashed passwords it's not possible to use digest authentication as far as they were not hashed using the same function.
I think the best solution for you here is create a login page and use cookie sessions to control the privileges of the users. With this solution you get the answer for the other questions:
我认为您可以首先使用用于在数据库中存储密码的相同函数对用户输入的密码进行哈希处理，然后将其作为摘要密码传递，其余过程将是相同的。
并且您必须在 HTTP URL 中传递用户名和密码，而不是普通形式
http://www.rojotek.com/博客/2008/05/19/http-authentication-in-a-url/
i think you can hash the user inputted password first with the same function used to store the passwords in the database, then pass it as a digest password and the rest of the procedure will be the same.
and you will have to pass username and password in the HTTP URL instead of the normal form
http://www.rojotek.com/blog/2008/05/19/http-authentication-in-a-url/