我写了一个小型网络服务器，目前使用基本身份验证而不是 ssl。到目前为止，一切都很好。现在我想（需要）切换到digest auth。但是我不知道如何使用未在数据库中以明文形式存储的密码来完成这项工作？我只存储了用户密码的密码摘要（使用 bcrypt 生成）。 http digest auth 有可能吗？
【问题讨论】：
标签： bcrypt digest-authentication
刚才正在研究这个。首先，我通读了RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication 以深入了解该规范，并了解它如何适用于 REST API 身份验证。
遇到了和你一样的问题——摘要式身份验证是否意味着服务器需要以明文形式存储用户密码？
This Stack Overflow 的回答很清楚：没有。服务器不存储明文密码—it should store the hash of (username|realm|password)。
除了一件事——规范规范只支持使用 MD5 作为散列函数之外，那本来可以的。
当然，您可以存储 both 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 的基本身份验证获得了任何额外的安全层？
【讨论】：
现在的问题变成了——所有这些增加的复杂性真的值得吗？我们是否通过 HTTPS 的基本身份验证获得了任何额外的安全层？
我可以看到一个，当您使用基本身份验证时，您的 HTTP 客户端将 Authorization 标头发送为 base64(password)
因此，如果您打开网络浏览器，并且有人打开浏览器网络控制台，他可以对您的密码进行 base64 解码。
而对于摘要身份验证，授权标头是 md5 哈希（并且包含随机数哈希以防止重放攻击）
【讨论】：
Authorization 标头并暴露base64(password)，因此在这种情况下，即使只是一个MD5 哈希也会增加一定的安全级别。 （我放弃了我的询问线，只使用了不透明的会话令牌或 JWT。）