使用 cookie 将加密的第三方密码安全地存储在数据库中答案

【问题标题】：Using cookies to securely store encrypted third-party passwords in DB使用 cookie 将加密的第三方密码安全地存储在数据库中
【发布时间】：2015-07-11 19:15:46
【问题描述】：

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

MySite 允许用户使用用户名和密码（或 Facebook，等等）进行注册！
如果该用户还使用用户名和密码在 AllTheData.com（此处称为 ATD）网站上注册，他们可以通过 HTTPS 向我提供这些信息。
MySite 接收到 ATD 的第三方凭据并做两件事：创建一个新的加密密钥，将其存储在用户的 cookie 中，并使用该密钥加密用户名和密码，并将这些加密值存储在数据库。

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

|用户 |密码 | JohnDoe@gmail.com | p4ssw0rd_hashed

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

并且用户的浏览器有一个带有key的cookie：

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

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

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

谢谢！

【问题讨论】：

为什么用户首先要将他们的凭据提供给您的第 3 方服务？（顺便说一句，许多网站的 ToS 都禁止这样做。）您的网站打算提供什么样的服务？
我绝对同意，这是一个不寻常的情况。我的公司使用只能以表格格式报告的 CRM，因此为了进行任何可视化，我们必须将数据下拉到 Excel 或其他一些数据可视化工具。这只是为了允许我们通过 API 提取数据并使用 D3 和其他好东西进行数据可视化，但是这个 CRM 只允许通过基本身份验证访问 API。

标签： security cookies encryption

【解决方案1】：

我同意 CBroe 的评论。与强迫用户放弃他们宝贵的凭据相比，与第三方交互的方式要好得多。我建议研究类似OAuth 的内容。它为您的用户提供了许多很棒的功能：

他们只向 ATD 出示其 ATD 凭证
ATD 可以让他们控制您的系统可以为他们执行的数据或操作。用户有权随时撤销您系统的访问权限。
您想要集成的大多数大型第三方已经是OAuth providers

由于您已声明 OAuth 不是一种选择，因此在使用您提出的解决方案之前，我会尝试另一种攻击计划。您已经承认您的解决方案非常短暂；一旦用户清除了他们的 cookie，您需要他们重新登录。如果您正在调用的服务在登录时创建会话，您可以简单地将用户凭据转发给第三方并临时缓存该服务通常会返回给用户的任何令牌或会话 ID（我认为没有理由将其存储在数据库中）。一旦您的用户退出您的系统，您就可以删除该令牌。这使您无法直接存储他们的凭据。这不是一个很大的进步，但这是我首先要追求的。

如果您将此与您的 cookie 加密想法结合起来，我认为您会得到一个很好的分离。您在服务器上缓存了加密的身份验证令牌，但只有将加密密钥存储为 cookie 的用户才能访问它。就像您说的那样，如果您受到威胁，这会阻止您的服务器向第三方提供访问权限。如果您的客户端遭到入侵，您并没有真正得到任何保护，但我认为这是不可避免的。

如果系统对每个请求都需要凭据，那么我真的没有看到更好的方法。你已经完成了你的作业，我没有看到任何更好的解决方案。

【讨论】：

完全！我 100% 同意，我应该提到 OAuth 不可能与我希望集成的服务一起使用！对其他人：这是真的，如果可以选择 OAuth，请不要这样做！
是的，我考虑过存储身份验证 cookie 而不是加密凭据。但是，这实际上更安全吗？我承认我不是 100% 了解这些 cookie 的安全性。似乎如果我的服务器受到该策略的破坏，攻击者将长时间访问每个人的服务，而使用上述方法，他们需要破坏我的服务器并从我的用户那里获取 cookie。这是一个正确的比较吗？
澄清一下，我并不是说您应该永久存储身份验证令牌，只需将其缓存在用户的会话中即可。至于您关于需要妥协双方（服务器和cookie）的评论，我认为您是对的。加密您用于访问第三方服务的任何内容并将加密密钥与数据分开会更加强大。我已经更新了我的答案以反映这一点。
非常感谢！感谢您的反馈，并将尝试这两种方法！

【解决方案2】：

这不是太糟糕，虽然不是允许访问第 3 方系统的最佳方式。

确保MySite_key 是由加密安全算法生成的，因此攻击者无法预测它，并尽您所能保护此 cookie。如果您的网站有任何违规行为，cookie 就会对攻击者非常有价值。当然，价值多少取决于用户在 ATD 中可以访问哪些数据。

这意味着在您的网站上实施 SSL/TLS，在 cookie 上强制执行 Secure Flag 和 HTTP Only Flag 并设置 HSTS policy。还要确保您的网站没有任何session fixation 漏洞 - 如果存在漏洞，攻击者可能能够为其他用户的帐户设置自己的加密密钥。

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

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

【讨论】：