4

不确定问题是否应该在ServerFault上？

我在我的服务器上使用Apache 凭据设置了 couchDB （但如果分散注意力，我可以将其关闭）。
我在各种笔记本电脑上有本地实例。现在我想设置安全（连续）复制。据我了解，我可以使用用户名/密码、SSL 证书或 OAuth。我找到了一些信息：

所有这些文件都增加了一种预感，但也令人困惑（我只是一个简单的头脑）。

我正在寻找的是分步说明：

  • OAuth 或 SSL 证书的优缺点（可选讨论）
  • 设置 SSL 组件的步骤 说明：我不是在寻找 SSL 传输安全性——这对于Apache HTTP和 CouchDB 来说并不复杂并且记录良好。我正在寻找的是使用证书进行身份验证，类似于您可以在 SSH 中执行的操作。我在 OAuth 中看到的潜在问题：管理员拥有对凭据 (?) 的完全访问权限。使用证书方法，他无法冒充用户，因为私钥不受管理员控制。
  • 设置 OAuth 的步骤
  • 每个用户的示例复制文档使用带有一些文档的本地副本并共享一个单线

我在哪里可以找到那个？

4

1 回答 1

5

用户凭据的安全传输是一个非常微妙的问题。

如果我们不考虑第三方，在大多数情况下，SSL 是更好的起点，因为它得到了您可能使用的每个工具的广泛支持。SSL 证书，不仅提供加密（甚至是自签名的），还提供用户请求正确资源的保险。如果您关心服务器安全性，最后一个选项也值得强调。SSL 使用的主要缺点是性能下降（因使用的算法而异），因为服务器必须解密数据，客户端需要验证证书以及常见的通信例程。此外，您还必须为受信任的证书支付一些钱（并非总是如此）。

使用 OAuth 允许不泄露真实的用户凭据并轻松地从服务器端维护他们的访问控制。此外，您需要一些能够正确处理 OAuth 1.0 规范的库，如果您的平台缺少此类库 - 您必须自己实现它。此外，OAuth 提供传输数据签名，因此它旨在确保 MiTM 案例的安全。这实际上就是他所做的一切。

正如您所注意到的，SSL 和 OAuth 是关于两个不同的事情：SSL 有助于在传输级别 (TLS) 上加密数据，而 OAuth 负责在非安全环境中泄露凭据。它们不能相互替代，但它们中的每一个都可以作为彼此的补充。

要为 CouchDB 设置 SSL 支持，只需遵循文档指南。这很简单，也很容易做到。请注意，如果 CouchDB 前面有一些代理服务器，最好为他设置 SSL 并通过常规 HTTP 协议将数据代理到本地 CouchDB 实例。

要设置 OAuth，需要执行以下步骤： 0. 确保{couch_httpd_oauth, oauth_authentication_handler}存在处理程序以用于配置文件的部分authentication_handlers选项：[httpd]default.ini

[httpd] authentication_handlers = {couch_httpd_oauth, oauth_authentication_handler}, {couch_httpd_auth, cookie_authentication_handler}, {couch_httpd_auth, default_authentication_handler}

之后，您需要通过以下方式编辑local.ini文件：

  1. 设置消费者秘密：
[oauth_consumer_secrets] 
example.org = sekr1t
  1. 设置令牌秘密：
[oauth_token_secrets] 
token1 = tokensekr1t
  1. 将令牌映射到现有的 CouchDB 用户：
[oauth_token_users] 
token1 = joe

就这样！如果您有 CouchDB 1.2 或更高版本，您还可以在数据库内的用户文档中定义 OAuth 凭据_users：

{
    "_id": "org.couchdb.user:joe",
    "type": "user",
    "name": "joe",
    "password_sha": "fe95df1ca59a9b567bdca5cbaf8412abd6e06121",
    "salt": "4e170ffeb6f34daecfd814dfb4001a73"
    "roles": ["foo", "bar"],
    "oauth": {
        "consumer_keys": {
            "example.org": "sekr1t",
            "consumerKey2": "key2Secret"
        },
        "tokens": {
            "token1": "tokensekr1t",
            "token2": "token2Secret"
       }
    }
}

现在，当我们为用户joe设置 OAuth 凭据时，让我们开始复制。为了让 CouchDB 使用 OAuth 凭据，我们需要扩展source或target字段，具体取决于哪一方将授权我们的用户：

{
    "source": "mailbox",
    "target": {
        "url": "https://secure.example.org/mailbox",
        "auth": {
            "oauth": {
                "consumer_secret": "sekr1t", 
                "consumer_key": "example.org", 
                "token_secret": "tokensekr1t", 
                "token": "token1" 
            }
        } 
    } 
}

并将POST此数据用于_replicate资源或为_replicator数据库创建文档。复制将使用 SSL 协议加密从本地服务器开始到远程服务器secure.example.org，所有操作都将针对登录的远程用户joe。

总结：SSL 和 OAuth 的结合不仅可以保护传输的数据（不仅是用户凭据）并确保目标服务器没有被伪造，还可以保护真实用户登录名和密码不被意外泄露，控制消费者来源（例如，如果example.org将妥协，我们只能删除他的消费者令牌，但不能强制用户更改他的密码）和签名请求以额外保护免受中间人攻击。

更新：对于您的情况，常规 SSL 证书例程是可以的：您需要创建由您自己签名的个人证书，并让客户端设置以进一步使用您的 CouchDB。CouchDB 方面唯一需要的是在处理连接之前验证证书。但请注意，自定义个人 SSL 证书安装可能并非易事，尤其是对于移动客户端。

说到 OAuth 方面，CouchDB可能会使用 RSA-SHA1 身份验证方法，该方法使用某种个人证书作为秘密。但是，您需要先修补源才能解锁此方法 - 默认情况下禁用。

于 2013-02-28T07:07:34.380 回答