我正在创建一个Web应用程序，该应用程序将在Youtube中使用OpenID登录名和OAuth令牌。我目前正在以纯文本格式在数据库中存储OpenID身份和OAuth令牌/令牌机密。
将这些值存储为纯文本是否不合适？我可以对OpenID标识符使用单向加密，但是我不知道这是否必要。对于OAuth令牌，我需要使用双向加密，因为我的应用程序需要获取会话令牌才能用于某些用途。
是否有必要对OpenID身份进行加密？有人可以使用它来访问用户帐户吗？
首先，存在具有consumer_key和consumer_secret的注册应用程序。
[当用户验证并“允许”您注册的应用程序时，您会得到：一个access_token，它被认为是用户的“密码”，并且允许您的应用程序代表用户执行操作。
因此，如果他们也没有access_token和consumer_key来进行完全访问，那么从数据库中仅获取用户的consumer_secret不会有太大帮助。
服务提供商应要求比较所有4个参数。在存储之前对这四个参数进行加密，然后在响应之前对其进行解密，将是明智的做法。
这只是当您需要代表用户更新或更改用户的资源所有者时。要使用户保持登录状态，请使用会话。
OAuth令牌和密钥显然都应该在数据库中保持安全，但是您不能像使用密码一样使用单向加密来存储它们。原因是您需要令牌和密钥才能签名请求。
[如果您正在运行OAuth服务器，也将是这种情况，您仍然需要原始令牌/秘密来验证请求。
如果需要，您仍可以使用AES等2种加密算法对它们进行加密，以在数据库或数据库备份受到破坏时提供安全性。
这里有两种思想流派。
第一个参数是：您应将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工作。