安全模式：使用用户凭据登录第三方站点

Question

我开发了一个服务（service），它自动化了用户可以在另一个第三方站点（第三方站点）上执行的某些操作。

“我的服务”为用户提供以下功能：

>

用户在服务中注册

1. 用户向服务提供其第三方站点用户名/密码
2. 该服务使用该凭据代表用户登录到第三方站点
3. 该服务将第三方站点发布的cookie存储在其数据库中
4. 从现在起，该服务开始使用以前存储的cookie（第三方站点的用户名/密码不会保存在任何位置）代表用户定期登录第三方站点（cron），并代表第三方站点的用户执行一些操作

笔记：

• 在注册服务之前，用户将获得描述服务和第三方网站之间交互的完整信息
• 有一定的价值在自动化用户的登录到第三方网站和用户有兴趣在第三方网站上自动化他们的登录和某些操作，即他们有兴趣在服务为他们在第三方做一些工作网站
• 第三方网站上没有OAuth功能
• 第三方网站上没有任何用户身份验证令牌功能

我在Stack Exchange进行了一项研究，但没有找到任何解决方案：

• https://security.stackexchange.com/questions/1335/storing-third-party-auth-info-securely
• 如何在我的应用程序中保存第三方应用程序的密码以与api一起使用
• 如何安全存储用于登录第三方网站的密码
• 存储第三方凭据的Rails。。有人知道最佳实践吗
• http://12factor.net/config
• https://security.stackexchange.com/questions/31535/need-to-ephemerally-store-third-party-password
• 我*必须*在数据库中存储第三方凭据。最好的办法
• 如何在django中安全地存储第三方服务的密码
• 当API调用要求以明文形式发送密码时，在数据库中存储密码的最佳方法是什么
• 德扬戈

此外，通过阅读提供的问题和答案，我倾向于认为没有办法保护用户的登录数据（密码或第三方网站cookie）。也就是说，如果攻击者能够访问服务的服务器，那么攻击者也可以访问第三方站点上的用户帐户。

如果我试图将第三方网站的cookie加密存储在服务的数据库中，那么它们将只对解密它们的脚本有用。因此，要访问第三方站点用户帐户，攻击者不仅需要访问服务的机器，还需要修改脚本（步骤4）。

在服务上为第三方站点存储cookie与OAuth非常相似，但在这种情况下，使用cookie代替令牌（不存储密码）。

如何设计安全模型/架构，将用户的登录数据安全地存储在服务上，以允许服务代表用户定期登录到第三方站点，而无需与用户进行手动交互？

另外，我使用Django，但我想安全模型/架构并不依赖于某个技术堆栈。

Answer 1

您的问题似乎特别询问了如何“安全地存储”凭证信息，因此让我先谈谈这个问题的狭隘方面。

安全地存储凭据信息

要存储的唯一信息是cookie，它是以明文形式获得的，将来需要以明文形式使用。这使您别无选择，只能使用双向加密，使用特定的“秘密”。为了使方案安全，您只需要保护您的“秘密”，最好将其嵌入到可编译的可执行模块中（例如，使用Java之类的编译语言）。这样，即使攻击者获得对整个计算机的访问权，他/她也无法解码cookie，除非运行您的程序并使用编译程序中内置的逻辑使用解码后的cookie。

整体架构考虑

如果问题是关于整体架构，如果没有OAuth或某些类型的令牌支持，您的机制将是不可靠的。因为服务会使cookie过期，您需要经常使用cookie访问服务，并说服服务永远不会使您的会话过期（因此cookie）。即使您这样做，一小时或几天后，或者当“服务”重新启动时，您的cookie将不再有效，您的访问将被拒绝。

Answer 2

显而易见：这里最重要的是不要让你网站上的攻击者访问所有cookie。您无法完全避免这种情况，因为您的服务将需要定期访问cookies（未加密的形式）。从理论上讲，完全破坏您的服务器的攻击者将能够执行您的服务可以执行的任何操作，因此，如果您的服务能够访问cookie，那么拥有所有权限的攻击者也将能够访问cookie。

如果你还想这样做，你应该

1） 使攻击者更难访问Cookie

举个例子来说明如何考虑这个问题：如果您的系统遭到破坏，攻击者很可能会访问您的文件系统。如果Cookie以纯文本形式存储在文件中，攻击者将会很容易。将它们存储在数据库中更好（也可能是您无论如何都想做的），但除非您以某种方式保护对数据库的访问，否则也好不到哪里去。如果数据库密码存储在应用程序配置文件中，专用攻击者将不会有困难。

一个将大大改善这种情况的解决方案是，如果cookie总是加密的，除非你需要它们。最好的解决方案是，如果加密密钥没有存储在应用程序日志中，而是在每次重新启动服务器时由操作员提供（键入）。要破解这个漏洞，攻击者必须读取应用程序的内存（并非完全不可能，但更困难）。

另一个措施是将cookie存储在专用服务器上的单独数据库中，并将对该服务器的所有访问限制在所需的范围内。

一个完整的策略需要对你的物理和逻辑设置有更深入的了解。

2）创建机制，以便您可以检测Cookie是否被泄露

这几乎同样重要。如果发生这种情况，你想知道并能够立即采取行动。当然，可以使用标准的入侵检测系统。您还可以创建适用于特定应用程序的更有针对性的系统。系统可以检测是否有人正在运行一个sql，该sql使用cookie扫描整个数据库表。由于您知道自己的应用程序通常的行为，您还可以创建一个监控系统，该系统可以检测是否发生了不正常的事情。

3）准备一个系统，以便在检测到所有cookie被盗时迅速使其无效

第三方服务可能有一个注销选项，从而使cookie失效。您应该为所有存储的cookie准备一份可以轻松激活的作业。想想在您禁用所有Cookie之前10分钟内告诉您的用户可能有人已经访问了他们的服务，以及告诉他们有人仍然可以访问第三方服务，而您不知道如何阻止他们的区别。

除此之外，您的用户理解他们在授予您访问权限时所做的事情以及第三方服务提供商对此的认可当然也很重要。第三方服务提供商是否会允许这种访问并不明显。如果他们这样做，他们还可以帮助您创建一个特殊会话cookie，即绑定到您的ip地址。