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

时间:2009-12-10 05:38:11

标签: database security encryption openid oauth

我正在创建一个将使用OpenID登录和OAuth令牌与Youtube一起使用的网络应用。我目前正在数据库中以纯文本格式存储OpenID标识和OAuth令牌/令牌密钥。

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

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

5 个答案:

答案 0 :(得分:27)

首先,注册的应用程序包含consumer_keyconsumer_secret

当用户验证并“允许”您注册的应用程序时,您会回来: access_token被视为用户的“密码”,并允许您的应用程序代表用户行事。

因此,如果用户的access_tokenconsumer_key没有完全访问权限,那么从数据库中获取用户的consumer_secret将无济于事。

服务提供商根据请求比较所有4个参数。在存储之前加密这4个参数并在响应之前解密它们将是明智的。

当您需要代表用户更新或更改用户的资源所有者时。要让用户登录您的网站,请使用会话。

答案 1 :(得分:19)

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

如果您正在运行OAuth服务器,您仍然需要原始令牌/机密来验证请求。

如果您愿意,您仍然可以使用双向加密算法(如AES)对它们进行加密,以便在数据库或数据库备份受到威胁时提供安全保护。

答案 2 :(得分:11)

这里有两种思想流派。

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

第二个论点是这样的:当某人有权访问您的数据库并且有足够的权限访问您的网络以进行中间人攻击时,您无论如何都会受到冲击。

我个人在谨慎方面犯了错误并加密了它们;这是密码的标准做法,所以你不妨给自己一点点额外的安心。

与此同时,谷歌有这样的建议:

“代币应该被视为与服务器上存储的任何其他敏感信息一样安全。”

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

网上的一些随机人员都有具体的实施建议:

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

http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/

答案 3 :(得分:0)

不应加密OpenID网址,因为这是您的“开放ID”字面意思,每个人都应该知道价值。此外,URL需要是数据库中的索引,加密数据库中的索引总是有问题的。

OAuth令牌/机密应该是保密的,如果您必须长期存储令牌,加密可以提高安全性。在我们的OAuth使用者应用程序中,令牌/机密仅在会话中存储了一段时间,我们选择不对它们进行加密。我觉得这很安全。如果有人可以查看我们的会话存储,他们可能也有我们的加密密钥。

答案 4 :(得分:0)

是的,这些应该在数据库中静止时对称加密(例如,CBC模式下的AES-256)。加密这些令牌的一种简单方法是使用SecureDB的加密作为服务RESTful API。

披露:我在SecureDB工作。