安全存储 OpenID 标识符和 OAuth 令牌

Posted 2023-03-08

【中文标题】安全存储 OpenID 标识符和 OAuth 令牌

【英文标题】：Securly Storing OpenID identifiers and OAuth tokens

【发布时间】：2010-12-25 03:07:21

【问题描述】：

我正在创建一个 Web 应用程序，它将在 Youtube 上使用 OpenID 登录和 OAuth 令牌。我目前正在数据库中以纯文本形式存储 OpenID 身份和 OAuth 令牌/令牌秘密。

将这些值存储为纯文本是否不合适？我可以对 OpenID 标识符使用单向加密，但我不知道这是否有必要。对于 OAuth 令牌，我需要使用双向加密，因为我的应用依赖于获取会话令牌以用于某些用途。

是否需要加密 OpenID 身份？有人可以使用它来访问用户的帐户吗？

【参考方案1】：

首先，有一个注册的应用程序有consumer_key 和consumer_secret。

当用户验证并“允许”您注册的应用程序时，您会返回： access_token 被视为用户的“密码”，并允许您的应用程序代表用户执行操作。

因此，如果用户没有consumer_key 和consumer_secret 的完全访问权限，那么仅从您的数据库中获取用户的access_token 将无济于事。

服务提供商根据请求比较所有 4 个参数。在存储之前加密这4个参数并在响应之前对其进行解密是很聪明的。

这只是当您需要代表用户更新或更改用户的资源所有者时。要让用户在您的网站上保持登录状态，请使用会话。

【讨论】：

如果您将 OAuth 2.0 与不记名令牌一起使用，则情况并非如此。您只需要一个访问令牌（身份验证令牌）即可访问用户数据。需要注意的事情。

【参考方案2】：

OAuth Token 和 Secret 显然都应该安全地保存在您的数据库中，但是您不能像使用密码一样使用单向加密来存储它们。原因是您需要令牌和密码才能签署请求。

如果您正在运行 OAuth 服务器，情况也是如此，您仍然需要原始令牌/密码来验证请求。

如果您愿意，您仍然可以使用 AES 等 2 路加密算法对其进行加密，以提供安全性，以防您的数据库或数据库备份受到威胁。

【讨论】：

其他答案说将它们视为密码，但这个答案很好，因为它指出您需要一种 2 路加密算法。使用散列密码，您可以散列用户键入的内容并检查散列密码。使用令牌和秘密，您需要重新获取原始文本。

2路加密算法？您是指像 RSA 这样的公钥加密（应该使用两个不同的密钥）吗？ AES 是“双向”，因为您可以加密和解密它，但只能使用相同的私钥。

@Lekensteyn 可能是 AES，与单向加密哈希函数相比，它是双向的。当您在同一环境中同时使用这两种方法时，公私密钥密码学不会给您带来太多好处。

【参考方案3】：

这里有两种思想流派。

第一个论点是：您应该将 OAuth 令牌视为密码。如果有人要访问您的数据库、获取所有 OpenID/OAuth 对并运行中间人攻击，他们就可以冒充您网站上的任何用户。

第二个论点是这样的：当有人可以访问您的数据库并充分访问您的网络以运行中间人攻击时，您无论如何都会被淹没。

我个人会谨慎行事，只是加密它们；这是密码的标准做法，因此您不妨让自己稍微安心一点。

同时，Google 有以下建议：

“应像对待存储在服务器上的任何其他敏感信息一样安全地对待令牌。”

来源：http://code.google.com/apis/accounts/docs/OAuth.html

网上一些随机的家伙有具体的实施建议：

如果它们位于常规磁盘文件上，请使用文件系统保护它们 权限，确保它们是 加密，并很好地隐藏密码 如果它们在数据库中，加密字段，存储密钥 好，并保护访问 数据库本身仔细。 * 如果他们在 LDAP 中，请执行相同操作。

archived post(original post URL, now a dead link)

【讨论】：

万一有人还在跟踪这个——我非常赞同加密这样的东西的想法，但它让我的新手大脑感到震惊，我们只是把问题推到另一个层次——我们可以加密，但现在我们必须将加密秘密放在某个地方，并防止 IT 被盗。将它放在 webroot 之外的某个文件中就足够了吗？

Web 服务器用户无法访问的 webroot 之外的文件（以防他们以这种方式获得）。或者一个单独的 PKI 基础设施，它只会变得很复杂。这可以防止攻击者找到一种方法来转储数据库而不是整个文件系统 - 例如通过 SQL 注入攻击。

@BenWalther Web 服务器无法访问的文件？但是 Web 服务器必须访问文件（纯文本令牌）才能与基于 OAuth 的服务进行交互。

【参考方案4】：

OpenID URL 不应该被加密，因为这是你的“open id”字面意思，每个人都应该知道这个值。此外，URL 需要是数据库中的索引，并且对数据库中的索引进行加密总是有问题的。

OAuth 令牌/机密应该是机密的，如果您必须长期存储令牌，加密可能会提高安全性。在我们的 OAuth 消费者应用程序中，令牌/秘密仅在会话中存储一小段时间，我们选择不加密它们。我认为这已经足够安全了。如果有人可以窥探我们的会话存储，他们可能也拥有我们的加密密钥。

【讨论】：

不完全正确。 OpenID URL 不一定是公开的。为了防止 RP 之间的关联，Google 使用定向身份，以便每个 RP 为同一用户获取唯一的 OpenID。如果所有这些都公开，以便每个人都知道这些值，那么相关性将再次成为可能。

OP 说的是后端数据库。它是公开的，你有更大的隐私问题需要处理。

【参考方案5】：

是的，这些应该在数据库中静止时进行对称加密（例如，CBC 模式下的 AES-256）。加密这些令牌的一种简单方法是使用SecureDB 的加密即服务 RESTful API。

披露：我在 SecureDB 工作。