Security 在仍然需要访问明文时安全地存储密码

可能重复：

我知道存储用户密码的最佳实践是只存储密码的不可逆散列

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

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

除了上述加密之外，我还可以采取哪些最佳做法或步骤来尽可能安全地进行加密

编辑

---

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

正如您所说，您的代码最终将需要密钥，因此，如果服务器受损，密码也将受损。这是没有办法的

您可以做的是使用一个非常小的代理，它的唯一任务是拥有密码、侦听来自主应用程序的请求、连接到有问题的服务，并将响应返回到应用程序。如果服务器上只运行一个非常简单的代理，那么它受到危害的可能性将比运行在具有许多服务的服务器上的复杂应用程序小得多。

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

好的。。。我通读了答案和评论，我能说的就是我希望你们有一支精干的法律团队。在我看来，您提供的服务是基于用户信任的。这是一个用户控制的交换机，而不是在他们背后做一些有益的事情，这很好，但我认为你需要一个真正铁的服务协议

也就是说，你可能会引发很多安全性妄想症。如果有人闯入，你必须根据对你的产品、公司和用户造成的伤害来计算你想要经历多少。以下是一些想法：

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

这是系统安全性高点的一个亮点。我的一般观点是——如果你真的想保护用户密码，你就不能只考虑数据。仅仅对密码进行加密不足以真正保护用户和维护信任

这个方法的标准方法是考虑成本和保护成本。如果两种成本都太高