安全处理纯文本密码...

时间:2019-08-30 17:39:08

标签: php security passwords backend

我正在一个网站上以简洁的方式从一个网站B输出数据,这比手动登录并在网站B上查找所有数据要快。

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

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

我已经考虑过哈希或加密,但是两者都要求它能够轻松地将其转换回纯文本密码(允许任何攻击者像我的系统一样容易地找到它),以便可以将其输入到网站中B进行网页抓取。

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

1 个答案:

答案 0 :(得分:1)

简单的答案是,您不能安全地执行此操作:

  • 用户需要信任您的凭据才能登录到远程网站,而大多数情况下不会。本质上,您所做的与网络钓鱼相同。作为最终用户,我如何使用我的凭据知道您在做什么?
  • 如果您的服务器发生违规行为且所有凭证泄漏或将代码注入到脚本中(将登录信息发送到黑客的数据库),您将承担责任。加密增加了一小层安全性,但是当用户首次登录时不需要私钥时,应用程序将需要使用纯文本以及登录数据来访问私钥。
  • 您正在使用其他网站,而不是使用API​​,这意味着HTML的任何细微更改都可能破坏您的网站。
  • 远程网站可以将代码注入您的网站。
  • 远程网站会将许多用户的许多登录记录到您服务器的IP上,并可能标记您和/或您的用户帐户中的可疑活动。
  • 您的服务器实际上成为登录的代理服务器,这意味着登录失败也将注册到您服务器的IP。再次,这可能会使您和您的用户被标记或列入黑名单,并且还使您有可能使用您的服务器对远程服务器进行暴力登录。
  • 如果远程服务器曾经实现多因素身份验证,则将增加一层复杂性;如果它使用Webauthn(例如U2F),则用户将无法通过您的服务器登录。

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