处理明文密码......安全

Handle Plaintext Passwords... Safely

我在一个网站上工作,该网站可以简洁地在一个视图中输出网站 B 的数据,这比手动登录并在网站 B 上查找所有数据要快。

它需要任何用户都可以使用。目前它可以工作,但需要用户使用网站 B 的凭据登录我的网站。网站 B 没有 API,这是我能想到的唯一方法。显然,这并不理想,因为用户名和密码是通过获取请求以明文形式发送到我网站上的 php 脚本并进行一些网络抓取的。我还可以选择将密码存储在用户 cookie 中(以明文形式),以便能够让用户保持登录状态。

我不会亲自为自己存储密码,但任何开发人员如果有恶意,都可以更改其后端以以纯文本形式存储密码。由于我没有恶意,归结为用户是否信任该网站,我更担心攻击者可能会从用户 cookie 或请求中获取这些密码。

我考虑过散列或加密,但两者都需要能够轻松地将它们变回明文密码(允许任何攻击者像我的系统一样容易找到它)以便可以输入它们进入网站 B 进行网页抓取。

这是一个两难选择,老实说,我想不出更好的解决方案。有什么可以使它至少更安全一点的吗?

简短的回答是,你不能安全地这样做:

  • 用户将需要信任您使用他们登录远程网站的凭据,而大多数人不会。你所做的与网络钓鱼本质上是一样的。作为最终用户,我如何知道您使用我的凭据做什么?
  • 如果您的服务器发生漏洞并且所有凭据被泄露,或者代码被注入您的脚本以将登录信息发送到黑客的数据库,您将承担责任。加密增加了一小层安全性,但是当用户首次登录时不需要私钥,应用程序需要以明文形式访问私钥以及登录数据。
  • 您没有使用 API,而是在抓取其他网站,这意味着 HTML 中的任何小改动都可能破坏您的网站。
  • 远程网站可以将代码注入您的网站。
  • 远程网站将记录许多用户登录到您服务器 IP 的许多登录信息,并可能将您 and/or 标记为可疑的用户帐户 activity。
  • 你的服务器本质上就是一个登录代理服务器,这意味着登录失败也会被注册到你服务器的IP上。这可能再次让您和您的用户被标记或列入黑名单,并且还开启了使用您的服务器强制登录到远程服务器的可能性。
  • 如果远程服务器实现了多因素身份验证,这会增加一层复杂性,如果它使用 Webauthn(例如 U2F),用户将无法通过您的服务器登录。

这正是 API 存在的原因。如果不存在,请联系远程网站并尝试说服他们为什么拥有一个很重要。如果它对您来说真的很重要,请提供代码。