使用Cookie将加密的第三方密码安全存储在数据库中

Question

显然，存储任何种类的第三方凭据都是一个主要风险，我想尽可能避免这种情况。 但是，我对如何相对安全有一个想法，我希望对此策略发表一些意见：

1. MySite允许用户使用用户名和密码（或Facebook，无论如何）进行注册！

2. 如果该用户还使用用户名和密码在AllTheData.com网站（此处称为ATD）上注册，则他们可以通过HTTPS给我这些用户名和密码。

3. MySite接收ATD的第三方凭据，并做两件事：创建一个新的加密密钥，将其存储在用户的cookie中，并使用该密钥对用户名和密码进行加密，并将这些加密的值存储在数据库中。

AllTheData.com的数据库可能如下所示：

| User               | Password              
| JohnDoe@gmail.com  | p4ssw0rd_hashed

MySite的数据库现在看起来像这样：

| User               | Password               | ATD_username         |ATD_pass
| JohnDoe@gmail.com  | another_p4ssw0rd_hashed| ct5lHMGymedITfElVA...|BHJCS38DkG7Zg0...

用户的浏览器具有一个带有密钥的cookie：

MySite_key: E3iKZxk2ZDD4EUb*fH$X6Mz5BO^iQeOM&V$lB0WAk4&WAB#A4QB8Yn7

现在，当我需要访问服务时，我从数据库中提取了加密的值，并从他们的请求中提取了cookie，然后就可以访问服务器了！ 当然，如果他们的cookie过期了，或者他们已经清除了它们或更换了计算机或其他任何东西，那么我不得不再次问：（但是，如果这意味着我不必将凭据存储在纯文本中，那是值得的！

我在这里做错什么了吗？ 这个计划有什么明显的问题吗？

谢谢！

Answer 1

我同意CBroe的评论。 与第三者进行交互的方法要比强迫您的用户放弃其宝贵的凭据要好得多。 我建议研究类似OAuth的东西。 它为您的用户提供了许多很棒的功能：

• 他们只向ATD出示其ATD凭证
• ATD可以让他们控制系统可以为他们执行的数据或操作。 用户可以随时撤消系统访问权限。
• 您想要与之集成的大多数第三方都是OAuth提供者

---

既然您已经说过不能使用OAuth，那么在使用您提出的解决方案之前，我会尝试另一种攻击计划。 您已经承认您的解决方案非常短暂。 一旦用户清除了他们的cookie，您就要求他们再次登录。 如果您要调用的服务在登录时创建了会话，则只需将用户凭据转发给第三方，然后临时缓存该服务通常返回给用户的任何令牌或会话ID（我认为没有理由将其存储在数据库中）。 一旦用户注销系统，您就可以删除该令牌。 这样可以避免直接存储其凭据。 这不是很大的进步，但这是我首先要追求的。

如果将此与cookie加密想法结合起来，我认为您将获得很好的分离。 您已经在服务器上缓存了加密的身份验证令牌，但是只有将加密密钥存储为cookie的用户才能访问它。 就像您说的那样，如果您受到感染，这将阻止您的服务器授予第三方访问权限。 如果您的客户受到损害，您实际上并没有得到任何保护，但是我认为这是不可避免的。

如果系统为每个请求都要求凭据，那么我真的看不到更好的方法。 您已完成作业，但没有更好的解决方案。

Answer 2

虽然不是允许访问第三方系统的最佳方法，但这也不错。

确保MySite_key是由加密安全算法生成的，以便攻击者无法预测到它，并尽最大可能保护此cookie。 如果您的网站上存在任何违规行为，则Cookie对于攻击者而言将变得非常有价值。 当然，是否有价值取决于用户在ATD中可以访问哪些数据。

这意味着在您的站点上实施SSL / TLS，在cookie上实施Secure Flag和HTTP Only Flag并设置HSTS策略 。 还要确保您的站点没有任何会话固定漏洞-如果存在，则攻击者可能能够为另一个用户的帐户设置自己的加密密钥。

确保加密算法也足够安全，可以满足您的需求，例如AES-128 。

还要确保您与ATD的通信仅通过SSL / TLS。 同样，使用被认为是安全的并且不易受到任何降级攻击（例如FREAK ）攻击的协议和密码套件版本。