我写了一个小型网络服务器，目前在ssl上使用基本身份验证。到目前为止一切都很好。现在我想（需要）切换到摘要身份验证。但我无法弄清楚如何使用未在数据库中以明文形式存储的密码来完成此工作？我只存储了用户密码的密码摘要（使用bcrypt生成）。是否可以使用http digest auth？
答案 0 :(得分：12)
刚才正在研究这个问题。首先，我通读RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication以深入了解规范，并了解如何针对REST API身份验证进行调整。
与您所做的问题相同 - 摘要验证意味着服务器需要以明文形式存储用户密码吗？
This Stack Overflow回答清楚地表明：不。服务器不存储明文密码 - it should store the hash of (username|realm|password)。
除了一件事之外，这样做会很好 - 规范规范只支持使用MD5作为哈希函数。
当然你可以存储两个 bcrypt哈希和 MD5哈希，但这样做只会破坏bcrypt哈希的安全性，有效地使它变得无用（因为攻击者可以将他的努力转移到暴力迫使MD5哈希代替）。
所以，我退后一步想，为什么不忽视规范并使用两个方面的bcrypt作为哈希函数（bcrypt(username|realm|password)）？
嗯，除了有目的地慢，bcrypt has a maximum password length makes it unsuitable for use as a general digest algorithm。
哇，到现在我的头还在游泳，但我还是想再给它一次。一些建议是使用带有SRP的TLS或经过身份验证的加密，特别是EAX，但我觉得也许那些对于简单的Web服务来说只是迈出了一小步。
简单地说，如果你真的愿意这样做，你可以work around bcrypt's character limitation by using a preliminary hash。
长话短说似乎你可以做到：
bcrypt(sha256(username|realm|password))
并在规范的标准版本中使用它代替H(A1)。
现在的问题是 - 所有增加的复杂性真的值得吗？我们是否通过HTTPS获得了基本身份验证的任何附加安全层？
答案 1 :(得分：1)
现在的问题是——所有增加的复杂性真的值得吗？我们是否通过 HTTPS 的基本身份验证获得了任何额外的安全层？
我可以看到一个，当您使用基本身份验证时，您的 HTTP 客户端将授权标头作为 base64(password)
因此，如果您让 Web 浏览器保持打开状态，而有人打开浏览器 Web 控制台，他就可以对您的密码进行 base64 解码。
然而，对于摘要认证，授权标头是一个 md5 哈希（并且包含一个随机数哈希以防止重放攻击）