安全模式：登录到第三方网站与用户的凭据 [英] Security model: log in to third-party site with user's credentials

查看：173
本文介绍了安全模式：登录到第三方网站与用户的凭据的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我制定了售后服务（Service），它可以自动为用户可在另一第三方网站（第三方网站）做某些动作

我的服务为用户以下功能：


  • 在服务中的用户注册


    1. 用户提供他/她的第三方网站的用户名/密码到服务

    2. 的服务使用凭证登录到第三方网站代表用户的

    3. 服务店由第三方网站在其数据库发布Cookie

    4. 从现在开始，在服务启动登录到代表用户在第三方网站的定期（cron的）使用previously存储的cookie（用户名/密码为第三方网站不保存任何地方）和执行上的第三方网站
      5. 用户代表的一些行动

的注：的


  • 在服务注册之前，用户是描述服务和第三方网站之间的相互作用的全部信息psented $ P $

  • 有一个在用户的登录自动到第三方网站有一定的价值和用户感兴趣的第三方网站自动化的登录和某些行动，即它们感兴趣的服务为他们做一些工作在第3党的网站

  • 没有对第三方网站
    • 无功能的OAuth
  • 没有对第三方网站
    • 没有任何用户身份验证令牌功能

我已经做了研究在这里堆栈Exchange和我还没有找到任何解决方案：

另外，从通过所提供的问题和答案我倾向于认为是没有办法，以确保用户的登录数据（密码或第三方站点的Cookie）读书。即如果攻击者获取到服务的服务器的访问，攻击者获得对第三方网站的访问用户的帐户以及

如果我尝试存储第三方网站在服务的数据库加密Cookie，然后他们将只对他们进行解密脚本有用。因此，要获得访问第三方网站的用户帐户，攻击者不仅需要得到服务的机器的访问，但修改脚本（步骤4）为好。

在服务存储的第三方网站的cookie是真的相似到OAuth，但在这种情况下使用的cookie代替令牌（没有密码被存储）。

什么是设计一个安全模型/架构，以安全地在服务存储用户的登录数据，以使服务能够登录到代表用户的第三方网站经常不与用户手动交互的方式吗？

的 P.S。我使用Django，但我猜的安全模型/架构不依赖于一定的技术堆栈。的


解决方案

不言自明的：这里最重要的当然是不要让您的网站，攻击者得到所有cookie的访问。你不能完全防止这一点，因为您的服务将需要访问Cookie（在未加密的形式）定期。这已经完全破坏服务器的攻击者会在理论上可以做任何事情，你的服务可以做的，所以如果有可能为您服务，可以访问饼干，然后用所有权限的攻击者也能获得访问它们。

如果您仍然想做到这一点，你应该

<强> 1）使其更难以攻击者访问该饼干

只给你，你可以如何看待这样一个例子：如果您的系统被攻破，则很可能是攻击者将能够访问你的文件系统。如果Cookie被存储在文件中明文，攻击者将有一个简单的时间。存储在数据库中他们是更好的（而且可能是你想要做的工作），但也好不到哪里去，除非你保护的访问以某种方式数据库。一个专门攻击者不会有如果，即密码的数据库存储在应用程序的配置文件中的一个困难时期。

这将改善情况的一个解决方案，如果相当饼干始终，除了刚刚当你需要他们的加密很多会。最好的解决办法是，如果加密密钥不存储在应用程序日志，但每次重新启动服务器时提供了（键入的）由操作员。为了打破这一攻击者必须读取应用程序（不是不可能在所有的，但仍然比较困难）的内存。

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

这一个完整的战略需要您确切的物理和逻辑设置的更深入的了解。

2）建立机制，这样很可能，你可以检测是否饼干被攻破

这几乎是同样重要的。如果发生这种情况，你想知道并能够立即采取行动。有当然可以使用标准的IDS系统。您还可以创建适用于您的应用程序spesific更有针对性的系统。如果有人运行与饼干扫描整个数据库表一个SQL系统可以检测，即。既然你知道你自己的应用程序正常的行为，你还可以创建一个监测系统，可以检测的东西是不正常的情况。

3）prepare快速无效所有Cookie的系统如果检测到这些被盗

第三方服务也可能不得不退出的选项，并通过无效的cookie。你应该prepare，这是否为所有存储的cookie，你可以很容易地激活工作。想想告诉你的用户，有人可能会在10分钟内已经获得他们的服务，然后禁用所有Cookie，并告诉他们，有人仍然可以访问第三方服务，你不知道如何阻止他们的区别。

除了这一点，当然重要的是你的用户了解当他们给你访问和的第三方服务提供商的这批他们做什么。这不是明显，第三方服务提供商将允许这种访问。如果他们这样做，他们也可以帮助你与创建是即绑定到你的ip地址的特殊会话cookie。

I develop a service (Service) which automates certain actions that users can do on another third-party site (3rd Party Site).

My service provides the following functionality for the users:

  • the user registers at the Service

    1. the user provides his/her 3rd Party Site username/password to the Service
    2. the Service uses that credentials to log in to the 3rd Party Site on the user's behalf
    3. the Service stores the cookie issued by the 3rd Party Site in its database
    4. from now on, the Service starts to log in to the 3rd Party Site regularly (cron) on the user's behalf by using the previously stored cookie (the username/password for the 3rd Party Site is not saved anywhere) and performs some actions on the users behalf on the 3rd Party Site

Notes:

  • before registering on the Service, the user is presented with the full information describing the interaction between the Service and the 3rd Party Site
  • there is a certain value in automating the user's login to the 3rd Party Site and users are interested in automating their logins and certain actions on the 3rd Party Site, i.e. they are interested in the Service doing some work for them at the 3rd Party Site
  • there is no OAuth functionality on the 3rd Party Site
  • there is no any user authentication token functionality on the 3rd Party Site

I have made a research here at Stack Exchange and I have not found any solutions:

Moreover, from reading through the provided questions and answers I tend to think there is no way to secure the user's login data (passwords or 3rd Party Site cookies). I.e. if an attacker gets an access to the Service's server, the attacker gets the access to the users' accounts on the 3rd Party Site as well.

If I try to store the 3rd Party Site's cookies in the Service's database encrypted, then they will be only useful to the script that decrypts them. Therefore, to get access to the 3rd Party Site user account, the attacker would need to not only get an access to the Service's machine, but to modify the script (step 4) as well.

Storing a cookie for the 3rd Party Site on the Service is really similar to OAuth, but in this case a cookie used instead of a token (no passwords are stored).

What is the way to design a security model/architecture to securely store user's login data at a service to allow the service to login to a third-party site on the user's behalf regularly without manual interaction with the user?

P.S. I use Django, but I guess that the security model/architecture does not depend on a certain technology stack.

解决方案

To state the obvious: The important thing here is of course to not let an attacker on your site get access to all the cookies. You cannot completely protect against this, since your service will need access to the cookies (in unencrypted form) regularly. An attacker that has completely compromised your server will in theory be able to do anything your service can do, so if it is possible for your service to get access to the cookies, then an attacker with all rights will also be able to get access to them.

If you still want to do this, you should

1) make it more difficult for an attacker to get access to the cookies

Just to give you an example of how you can think about this: If your system is compromised, it is likely that the attacker will get access to your file system. If the cookies are stored in plain text on files, the attacker will have an easy time. Storing them in a database is better (and probably what you want to do anyway), but not much better unless you protect access to the database in some way. A dedicated attacker will not have a hard time if i.e. the password to the database is stored in the applications configuration file.

A solution that would improve the situation quite a lot would be if the cookies always was encrypted except just when you need them. The best solution would be if the encryption key was not stored in an application log, but was provided (typed in) by an operator every time the server is restarted. To break this the attacker would have to read the memory of the application (not impossible at all, but still more difficult).

Another measure would be to store the cookies in a separate database on a dedicated server and limit all access to this server to what is needed.

A complete strategy for this requires more intimate knowledge of your exact physical and logical setup.

2) create mechanisms so that it is likely that you can detect if the cookies was compromised

This is almost equally important. If this happens, you want to know and be able to take action immediately. There are of course standard IDS systems that can be used. You may also create more targeted systems that applies to your spesific application. The system could i.e. detect if someone is running an sql that scans the whole database table with cookies. Since you know how your own application normally behaves, you can also create a monitoring system that can detect if something that is not normal happens.

3) prepare a system for quickly invalidating all cookies if you detect that they are stolen

The third party services does probably have an option to log out and by that invalidate the cookies. You should prepare a job that does this for all your stored cookies that you can easily activate. Think about the difference in telling your users that someone may have had access to their service in 10 minutes before you disabled all cookies and telling them that someone still have access to the third party service and you don't know how to stop them.

In addition to this, it is of course important that your users understand what they do when they give you access and that the provider of the third party services approves of this. It is not obvious that a third party service provider will allow this kind of access. If they do, they may also help you with creating a special session cookie that is i.e. bound to your ip address.

这篇关于安全模式：登录到第三方网站与用户的凭据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
ASP .NET最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆