logo标签列表

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

databasesecurityencryptionopenidoauth
60

我正在创建一个web应用程序，它将使用OpenID登录和OAuth令牌与Youtube进行交互。目前我将OpenID身份和OAuth令牌/令牌密钥以明文形式存储在数据库中。

将这些值作为明文存储是否不妥？对于OpenID标识符，我可以使用单向加密，但我不知道是否有必要。对于OAuth令牌，我需要使用双向加密，因为我的应用程序依赖于获取会话令牌来完成某些操作。

是否有必要加密OpenID身份？有人能够利用它来访问用户的帐户吗？

5个回答
27

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

当用户进行身份验证并"允许"你的注册应用程序后，你会收到一个access_token，被视为用户的"密码"，只有你的应用程序才能代表用户行事。

因此，如果他们没有完整访问所需的consumer_key和consumer_secret，仅从数据库获取用户的access_token是没有太多用处的。

服务提供商在请求时比较这4个参数。在存储之前将这4个参数加密，并在响应之前解密是明智的选择。

这仅适用于需要代表用户更新或更改用户资源所有者时。要保持用户在您的网站上登录，请使用会话。

36
如果您使用OAuth 2.0和Bearer令牌，则情况就不同了。您只需要访问令牌（授权令牌）即可访问用户数据。需要注意的是。 - FajitaNachos
19

OAuth令牌和密钥显然应该在您的数据库中保持安全，但是您不能像对待密码一样使用单向加密来存储它们。原因是您需要令牌和密钥来对请求进行签名。

如果您运行OAuth服务器，仍然需要原始的令牌/密钥来验证请求，这也适用于此情况。

如果您愿意，仍然可以使用双向加密算法（如AES）对它们进行加密，以提供安全性，以防止您的数据库或数据库备份被攻击。

2
其他答案说要像密码一样处理它们，但这个答案很好，因为它指出你需要一个双向加密算法。使用哈希密码，您可以对用户输入进行哈希处理，并根据哈希密码进行检查。对于令牌和密钥，您需要再次获取原始文本。 - paulmorriss
双向加密算法？你是指像RSA这样需要使用两个不同密钥的公钥加密吗？AES在某种意义上是“双向”的，因为你可以使用相同的私钥进行加密和解密。 - Lekensteyn
3
@Lekensteyn可能是指AES，与单向密码散列函数相比，AES是双向的。当您在同一环境中同时使用公钥私钥加密时，并不能为您带来很大的好处。 - skeggse
14

这里有两种不同的观点。

第一种观点是：应该像处理密码一样处理OAuth令牌。如果有人访问了您的数据库，获取了所有的OpenID/OAuth配对并进行中间人攻击，他们就可以冒充站点上的任何用户。

第二个观点是：当有人可以访问您的数据库并且拥有足够的访问权限来运行中间人攻击时，您已经陷入麻烦了。

我个人倾向于谨慎行事并将它们加密；这是密码的标准做法，这样你就可以多一点安心。

与此同时，Google给出了以下建议：

“令牌应该像服务器上存储的其他敏感信息一样受到安全保护。”

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

一些网上的随机人士给出了具体的实现建议：

  • 如果它们在常规磁盘文件上，请使用文件系统权限进行保护，确保它们被加密，并且要将密码隐藏好
  • 如果它们在数据库中，请加密这些字段，将密钥保存好，并仔细保护对数据库本身的访问。*
  • 如果它们在LDAP中，请执行相同的操作。

存档帖子（原始帖子网址，现已失效）

2
如果还有人在追踪这个问题——我非常同情像这样加密的想法，但是它让我的新手大脑认为，我们只是把问题推到了另一个级别——我们可以加密，但现在我们必须将加密密钥放在某个地方，并保护它不被盗取。只将其放在 Webroot 外部的某个文件中是否足够？ - Jim Miller
2
一个位于Web根目录之外的文件，Web服务器用户无法访问（以防他们通过这种方式进入）。或者使用单独的PKI基础设施，它可以处理各种复杂情况。这可以保护免受攻击者的攻击，即使他们通过SQL注入攻击找到了转储数据库的方法，也无法获取整个文件系统。 - Ben Walther
2
@BenWalther 一个Web服务器无法访问的文件？但是Web服务器必须访问该文件（明文令牌）以便与基于OAuth的服务进行交互。 - panzi
1

OpenID的URL不应该被加密，因为这是你的“开放ID”，每个人都应该知道它的值。此外，URL需要成为数据库中的索引，而在数据库中加密索引总是有问题的。

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

并不完全正确。OpenID URL并不一定是公开的。为了防止RPs之间的关联，Google使用定向身份，以便每个RP都为同一用户获得唯一的OpenID。如果所有这些都被公开，以至于每个人都知道这些值，那么关联将再次成为可能。 - Andrew Arnott
OP在谈论后端数据库。如果那是公开的，你将面临更大的隐私问题需要处理。 - ZZ Coder
0

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

声明：我在SecureDB工作。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接