数据库中的加密密码和浏览器摘要认证

Question

我写了一个小型的Web服务器，目前使用基本认证和SSL。到目前为止，一切都很顺利。现在我想（需要）切换到摘要认证。但是，我不知道如何将这种方法与数据库中未以明文形式存储的密码结合起来使用。我只有用户密码的密码摘要（使用bcrypt生成）存储在数据库中。是否可以使用HTTP摘要认证？

- gucki

---

我从未见过任何人使用摘要认证。只是好奇：你的用途是什么？与基本认证+HTTPS相比有什么优势吗？ - Sergey Ponomarev

Answer 1

我刚才在看这个。首先，我阅读了RFC 2617 - HTTP身份验证：基本和摘要访问认证来了解规范并了解如何将其适应于REST API身份验证。

我遇到了你所遇到的同样的问题——摘要身份验证是否意味着服务器需要以明文存储用户密码？

这个 Stack Overflow答案清楚地表明：不是的。服务器不会存储明文密码——它应该存储 (用户名|域|密码) 的哈希值。

那本来是没问题的，但有一个问题——规范只支持使用MD5作为哈希函数。

当然，你可以同时存储bcrypt哈希和MD5哈希，但这样做只会破坏bcrypt哈希的安全性，从而使其无效（因为攻击者可以转移他的努力去暴力破解MD5哈希）。

---

所以，我退了一步，想，为什么不无视规范，在两个方面都使用bcrypt作为哈希函数（bcrypt(用户名|域|密码)）？

好吧，除了故意变慢之外，bcrypt有一个最大密码长度，这使得它不适合用作通用摘要算法。

---

哇，现在我头晕目眩了，但我仍然想再试一次。其中一些建议是使用TLS与SRP或经过身份验证的加密，特别是EAX，但我觉得也许这些对于一个简单的Web服务来说有点过分了。

简而言之，如果你真的想做到这一点，可以通过使用预处理哈希解决bcrypt的字符限制问题。

---

长话短说，看起来你可以做到：

bcrypt(sha256(username|realm|password))

在规范的变种中，使用它替代H（A1）。

现在问题变成了 - 所有这些增加的复杂性真的值得吗？相比于基本身份验证在 HTTPS 上，我们是否获得了任何额外的安全层？

- Alistair A. Israel

---

虽然事件已经过去很久了，但这是非常好的澄清 - 我通常避免发表仓促的“感谢”评论，但这确实帮助我理解摘要认证的限制 :) - ChrisV

谢谢这个答案，证实了我的担忧。我有一个需要支持摘要认证的遗留应用程序。我希望将我们的密码存储转移到Bcrypt上，但我猜那是不可能的。 叹气 - Porco

Answer 2

现在的问题是：所有这些额外的复杂性真的值得吗？与HTTPS上的基本身份验证相比，我们是否获得了任何额外的安全层面？

我可以看到一个，当您使用基本身份验证时，您的HTTP客户端将Authorization标头发送为base64（密码）

因此，如果您让您的Web浏览器保持打开状态，并且有人打开了浏览器Web控制台，则他可以对您的密码进行base64解码。

而使用摘要身份验证时，Authorization标头是md5哈希（并包括nonce哈希以防止重放攻击）。

- Christophe L.

---

好的观点。此外，服务器日志可能无意中捕获“Authorization”头并公开“base64（password）”，因此即使只是MD5哈希，在这种情况下也增加了一定的安全级别。（我放弃了我的调查线路，只使用不透明会话令牌或JWT。） - Alistair A. Israel