CouchDB身份验证

Question

我读过很多关于CouchDB身份验证的内容，特别是关于Cookie身份验证。 我还在做一些测试，一切似乎与此命令运行良好，例如：

卷曲-vx POST $ HOST/_session -H“应用/的X WWW的形式，进行了urlencoded” -D' name = foo & password = bar'

我得到一个我可以使用的Cookie。 但我的观点是，无论何时，当我看到Web上的样本时，用户名和密码总是以纯文本形式发送。

我对安全性并不陌生，但如果我首先必须清楚地发送我的凭据，那么Cookie Auth方法的优点是什么？

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

卷曲-vx POST $ HOST/_session -H '应用/的X WWW的形式，进行了urlencoded' -D '名称= foo的& hashed_pa​​ssword = hashed_bar'

干杯

阿尔诺

Answer 1

如果你把你的密码散列比所有的攻击者需要知道的是你的哈希密码所以它不会解决在发送明文密码的问题 - 现在你会公顷存在以明文形式发送哈希的问题。

还要记住，即使解决了这个问题，您仍然会以明文形式发送您的cookie，从而容易受到会话劫持的影响。

（另外还有HTTP摘要访问认证，但并非没有自己的问题 - 但CouchDB的不支持它，我检查反正最后一次）

你应该做的是要始终使用HTTPS进行任何身份验证的CouchDB通过任何网络访问，除了127.0.0.0网络。

（是的，几乎所有的Web 的例子和书显示了使用通过HTTP这在我看来是一个等待发生的灾难的基本或cookie认证。）

Answer 2

随着1.1版本，CouchDB支持通过HTTPS访问API。您可以直接使用HTTPS，而不是使用HTTPS代理，以保护通过线路传输的密码。请参阅Feature Guide获取1.1。

Answer 3

使用Https是正确的答案。

我会补充说明计算服务器端散列的重要性。 哈希是一种单向函数，将输入转换为存储在服务器中的键值。如果有人攻击服务器并获得散列输入（键值），他将无法从中推导出输入值来模拟你。

如果您计算客户端的密钥值，并且没有任何一种方式在服务器上执行转换，它相当于以明文形式存储密码。设法获取存储在服务器上的密钥值的副本的人可以通过简单地发送密钥值轻松地模拟您。

因此，为了保护密码数据库，需要在服务器端应用在提交的密码上具有加密/随机种子的密码安全的单向函数（即，256）。

通过散列发送的密码除了在服务器端对其进行散列处理之外，如果发送的散列值始终相同，将无助于突变。然而，通过SSL连接发送的间谍数据并不是微不足道的。

然而，在客户端散列密码有一个重大的好处。通过尝试使用通用密码字典猜测密码，服务器上的暴力攻击将变得无望，因为客户端的散列会随机化密码。

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

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