CouchDB 身份验证答案

【问题标题】：CouchDB AuthenticationCouchDB 身份验证
【发布时间】：2011-02-23 14:07:15
【问题描述】：

我已经阅读了很多关于 CouchDB 中的身份验证的内容，尤其是关于 Cookie 身份验证的内容。我仍在进行一些测试，一切似乎都运行良好，例如使用此命令：

curl -vX POST $HOST/_session -H 'application/x-www-form-urlencoded' -d 'name=foo&password=bar'

我得到了一个我可以使用的 Cookie。但我的观点是，每当我在网络上看到 think 样的样本时，用户名和密码总是以纯文本形式发送。

我真的是安全新手，但是如果我首先必须清楚地发送我的凭据，那么 Cookie 身份验证方法有什么好处？

有没有办法至少发送散列密码？使用类似 IDK 的东西：

curl -vX POST $HOST/_session -H 'application/x-www-form-urlencoded' -d 'name=foo&hashed_password=hashed_bar'

干杯

阿诺

【问题讨论】：

【解决方案1】：

如果您发送的密码经过哈希处理，攻击者只需要知道您的哈希密码，因此它无法解决以明文形式发送密码的问题 - 现在您将遇到以明文形式发送哈希值的问题。

还请记住，即使这样解决了问题，您仍然会以明文形式发送 cookie，容易受到会话劫持。

（还有 HTTP 摘要访问身份验证，但并非没有问题 - 但 CouchDB 上次我检查时不支持它。）

您应该做的是始终使用 HTTPS 对涉及任何网络的任何经过身份验证的 CouchDB 访问，可能除了 127.0.0.0 网络。

（是的，几乎所有网络上的示例和都显示了通过 HTTP 使用基本或 cookie 身份验证，在我看来这是一场等待发生的灾难。）

【讨论】：

谢谢，所以我打算使用 HTTPS 以及对于安全性不是大问题的小应用程序，我想管理我的数据库管理员和数据库用户（读者），这样服务器管理员凭据永远不会使用是一个很好的解决方案？

【解决方案2】：

使用 Https 是正确的答案。

我将澄清在服务器端计算哈希的重要性。哈希是将输入转换为存储在服务器中的键值的单向函数。如果有人入侵服务器并获得散列输入（键值），他将无法从中推断输入值来冒充您。

如果你在客户端计算key值，而在服务器端没有进行单向转换，则相当于明文存储密码。设法获得存储在服务器上的键值副本的人只需发送键值即可轻松冒充您。

因此，需要在服务器端应用加密安全的单向函数（即 sha256），并在提交的密码上使用盐/随机种子来保护密码数据库。

通过散列来混淆发送的密码，除了在服务器端对其进行散列之外，如果发送的散列值始终相同，则无济于事。然而，通过 SSL 连接发送的间谍数据并非易事。

然而，在客户端散列密码有一个显着的好处。通过尝试使用通用密码字典猜测密码来对服务器进行暴力攻击将变得毫无希望，因为客户端的散列随机化了密码。

我们可能会在哈希中添加一些盐以防止使用哈希密码字典。当用户输入他的用户 ID 时，向服务器询问用户特定的盐值。然后使用返回的盐或哈希种子值在客户端生成哈希密码。

通过增加重试之间的时间间隔，可能会在服务器端阻碍暴力密码猜测。但这通常适用于一个特定的连接。攻击者可能在每两次尝试后重新连接。然后需要跟踪 IP 地址以识别此类攻击。

【讨论】：

【解决方案3】：

从 1.1 版开始，CouchDB 支持通过 HTTPS 访问 API。您可以直接使用 HTTPS，而不是使用 HTTPS 代理，从而保护通过网络传输的密码。请参阅 Feature Guide 了解 1.1。

【讨论】：