我正在创建一个web应用程序,它将使用OpenID登录和OAuth令牌与Youtube进行交互。目前我将OpenID身份和OAuth令牌/令牌密钥以明文形式存储在数据库中。
将这些值作为明文存储是否不妥?对于OpenID标识符,我可以使用单向加密,但我不知道是否有必要。对于OAuth令牌,我需要使用双向加密,因为我的应用程序依赖于获取会话令牌来完成某些操作。
是否有必要加密OpenID身份?有人能够利用它来访问用户的帐户吗?
我正在创建一个web应用程序,它将使用OpenID登录和OAuth令牌与Youtube进行交互。目前我将OpenID身份和OAuth令牌/令牌密钥以明文形式存储在数据库中。
将这些值作为明文存储是否不妥?对于OpenID标识符,我可以使用单向加密,但我不知道是否有必要。对于OAuth令牌,我需要使用双向加密,因为我的应用程序依赖于获取会话令牌来完成某些操作。
是否有必要加密OpenID身份?有人能够利用它来访问用户的帐户吗?
首先,有一个已注册的应用程序,包含consumer_key
和consumer_secret
。
当用户进行身份验证并"允许"你的注册应用程序后,你会收到一个access_token
,被视为用户的"密码",只有你的应用程序才能代表用户行事。
因此,如果他们没有完整访问所需的consumer_key
和consumer_secret
,仅从数据库获取用户的access_token
是没有太多用处的。
服务提供商在请求时比较这4个参数。在存储之前将这4个参数加密,并在响应之前解密是明智的选择。
这仅适用于需要代表用户更新或更改用户资源所有者时。要保持用户在您的网站上登录,请使用会话。
OAuth令牌和密钥显然应该在您的数据库中保持安全,但是您不能像对待密码一样使用单向加密来存储它们。原因是您需要令牌和密钥来对请求进行签名。
如果您运行OAuth服务器,仍然需要原始的令牌/密钥来验证请求,这也适用于此情况。
如果您愿意,仍然可以使用双向加密算法(如AES)对它们进行加密,以提供安全性,以防止您的数据库或数据库备份被攻击。
这里有两种不同的观点。
第一种观点是:应该像处理密码一样处理OAuth令牌。如果有人访问了您的数据库,获取了所有的OpenID/OAuth配对并进行中间人攻击,他们就可以冒充站点上的任何用户。
第二个观点是:当有人可以访问您的数据库并且拥有足够的访问权限来运行中间人攻击时,您已经陷入麻烦了。
我个人倾向于谨慎行事并将它们加密;这是密码的标准做法,这样你就可以多一点安心。
与此同时,Google给出了以下建议:
“令牌应该像服务器上存储的其他敏感信息一样受到安全保护。”
来源:http://code.google.com/apis/accounts/docs/OAuth.html
一些网上的随机人士给出了具体的实现建议:
OpenID的URL不应该被加密,因为这是你的“开放ID”,每个人都应该知道它的值。此外,URL需要成为数据库中的索引,而在数据库中加密索引总是有问题的。
OAuth令牌/密钥应该是保密的,如果您必须长期存储令牌,则加密可能会提高安全性。在我们的OAuth消费者应用程序中,令牌/密钥仅在会话中短暂存储,我们选择不加密它们。我认为这已经足够安全了。如果有人可以窥视我们的会话存储,他们可能也拥有我们的加密密钥。
是的,这些应该在数据库中静态加密(例如,在CBC模式下使用AES-256进行对称加密)。加密这些令牌的简单方法是使用SecureDB的加密即服务RESTful API。
声明:我在SecureDB工作。