当仍然需要访问明文时安全地存储密码[重复]

Question

可能重复：
PHP 2-way encryption: I need to store passwords that can be retrieved

我知道存储用户密码的最佳做法是只存储密码的不可逆哈希。

但是，我正在开发一个应用程序，我需要在其中存储另一个 Web 服务的用户登录信息——我需要定期让他们登录并执行一些维护任务。不幸的是，该服务不提供授权令牌，因此我（非常担心）必须以可以访问其纯文本值的方式存储密码。我不拥有或控制我正在对其进行身份验证的服务，唯一的方法是“借用”用户的用户名和密码并进行身份验证。

我计划对数据库中的密码进行 AES_ENCRYPT，这意味着如果有人能够以某种方式访问​​数据库，他们将无法获得明文。但是，我的代码需要访问密钥才能对其进行解密，因此，如果整个服务器遭到破坏，则没有保护措施，并且密码将被泄露。

除了上述加密之外，我是否可以采取任何最佳做法或步骤来尽可能安全地执行此操作？

编辑

我知道无论我做什么，最终密码都必须以明文形式访问，因此受感染的服务器意味着密码将被泄露，但我想知道我可以采取哪些步骤来降低风险。例如。在数据库受到威胁但不是整个服务器的情况下，加密数据库可以保护我。其他类似的缓解措施将不胜感激。

Answer 1

但是，我正在开发一个应用程序，我需要在其中存储另一个 Web 服务的用户登录信息——我需要定期让他们登录并执行一些维护任务。 p>

好的...我通读了答案和 cmets，我只能说我希望您拥有出色的法律团队。在我看来，您提供的服务是基于用户信任的。它是一个用户控制的开关，这很好，而不是在他们背后做一些有益的事情，但我认为你需要一个真正铁定的服务协议。

也就是说，您可以调用很多安全偏执狂。如果发生闯入，您必须根据对您的产品、您的公司和用户的伤害来计算您想要经历多少。以下是想法：

• 数据存储 - 将密码存储在远离攻击者可以进入的地方。高度访问受控文件，后端计算机上的数据库等。使任何攻击者都必须通过层层防御才能到达该位置数据被存储。同样具有网络保护，如防火墙和最新的安全补丁。这里没有任何事情是孤立地起作用的。
• 加密 - 任何加密技术都是一种延迟策略 - 攻击者一旦掌握了您的数据，他们最终会在无限长的时间内破解您的加密。因此，大多数情况下，您的目标是让它们放慢足够长的时间，以便系统的其余部分发现您已被黑客入侵，提醒您的用户，并让用户有时间更改密码或禁用帐户。 IMO - 对称或非对称加密都可以工作 - 只要您安全地存储密钥。作为一名 PKI 人员，我倾向于使用非对称加密，只是因为我更了解它并且知道许多 COTS 硬件解决方案可以非常安全地存储我的私钥。
• 密钥存储 - 您的加密仅与您的密钥存储一样好。如果密钥就在加密数据旁边，那么攻击者不需要破解你的密码，他们只需使用密钥就可以了。 HSM（硬件安全模块）是密钥存储的高端选择 - 在较高范围内，这些是防篡改的安全盒，既可以保存您的密钥，也可以为您执行加密。在低端，USB 令牌或智能卡可以执行相同的功能。其中一个关键部分是，最终，最好让管理员在服务器启动时激活密钥访问。否则，当您试图弄清楚如何安全地存储最终密码时，您最终会遇到鸡与蛋的情况。
• 入侵检测 - 拥有一个良好的系统，如果您被黑客入侵，很有可能会发出警报。如果您的密码数据被泄露，您希望在任何威胁之前向您的用户传达信息。
• 审计日志 - 对谁在系统上做了什么有很好的记录 - 特别是在您的密码附近。虽然您可以创建一个非常棒的系统，但特权用户做坏事（或愚蠢）的威胁与外部威胁一样严重。典型的高端审计系统以一种高特权用户无法查看或篡改的方式跟踪高特权用户的行为 - 相反，有第二个“审计员”帐户只处理审计日志，不处理其他任何事情。李>

这是系统安全性的一大亮点。我的一般观点是 - 如果您认真对待保护用户密码，您不能只考虑数据。仅仅加密密码可能不足以真正保护用户和维护信任。

解决此问题的标准方法是考虑开发成本与保护成本。如果这两项成本对于该功能的价值来说都太高了，那么您就有一个很好的迹象表明您不应该费心去做...

Answer 2

正如您所说，您的代码最终将需要密钥，因此如果服务器受到破坏，密码也将受到影响。没有办法解决。

您可以做的是拥有一个非常小的代理，其唯一工作就是获取密码、监听来自您的主应用程序的请求、连接到相关服务并将响应返回给您的应用程序。如果服务器上运行的只是这个非常简单的代理，那么与运行在具有许多服务的服务器上的复杂应用程序相比，它受到攻击的可能性要小得多。