Possible Duplicate:
PHP 2-way encryption: I need to store passwords that can be retrieved
我知道存储用户密码的最佳实践是仅存储不可逆的密码哈希。
但是，我正在开发一个应用程序，我需要在其中存储另一个 Web 服务的用户登录信息 - 我需要定期登录它们并执行一些维护任务。不幸的是，该服务不提供授权 token ，因此我(非常担心)必须以可以访问其纯文本值的方式存储密码。我不拥有或控制要验证的服务，唯一的方法是“借用”用户的用户名和密码并进行验证。
我计划对数据库中的密码进行 AES_ENCRYPT，这意味着如果有人能够以某种方式访问数据库，他们将无法获取明文。然而，我的代码需要访问 key 才能解密它们，因此，如果整个服务器遭到破坏，这将不再是保护措施，密码也会被泄露。
除了上述加密之外，我还可以采取哪些最佳实践或步骤来尽可能安全地执行此操作？
编辑
我知道，无论我做什么，最终密码都必须能够以明文形式访问，因此受感染的服务器意味着密码将被泄露，但我想知道我可以采取哪些步骤来降低风险。例如。在数据库受到威胁但不能保护整个服务器的情况下，加密数据库可以保护我。其他类似的缓解措施将不胜感激。
最佳答案
但是，我正在开发一个应用程序，我需要在其中存储另一个 Web 服务的用户登录信息 - 我需要定期登录它们并执行一些维护任务。 p>
好的...我通读了答案和评论，我所能说的就是我希望你们拥有精干的法律团队。在我看来，您提供的服务取决于用户的信任。这是一个用户控制的开关，而不是在他们背后帮忙做的事情，这很好，但我认为您需要对此有一个真正铁定的服务协议(protocol)。
也就是说，您可能会引发很多安全偏执。您必须根据发生入侵事件对您的产品、公司和用户造成的损害来确定您想要承受的损失有多大。想法如下:
- 数据存储 - 将密码存储在远离攻击者可以进入的地方。高度访问控制的文件、后端计算机上的数据库等。使任何攻击者必须穿过层层防御才能到达该位置数据被存储。同样有网络保护，如防火墙和最新的安全补丁。这里没有任何一件事是孤立运作的。
- 加密 - 任何加密技术都是一种延迟策略 - 一旦攻击者拥有您的数据，他们最终会在无限长的时间内破解您的加密。因此，大多数情况下，您的目标是让它们慢下来足够长的时间，以便系统的其余部分发现您已被黑客攻击，提醒用户，并给用户时间更改密码或禁用帐户。 IMO - 只要您安全地存储 key ，对称或非对称加密都可以工作。作为一名 PKI 人员，我倾向于非对称加密，因为我对它有更好的理解，并且了解许多 COTS 硬件解决方案，这些解决方案可以非常安全地存储我的私钥。
- key 存储 - 您的加密效果取决于您的 key 存储。如果 key 位于加密数据旁边，那么攻击者不需要破解您的加密，他们只需使用 key 即可。 HSM(硬件安全模块)是 key 存储的高端选择 - 在高端范围内，这些是防篡改的安全盒，既可以保存您的 key ，又可以为您执行加密。在低端，USB token 或智能卡可以执行相同的功能。其中一个关键部分是，最终最好让管理员在服务器启动时激活 key 访问。否则，当您试图弄清楚如何安全地存储最终密码时，您最终会遇到先有鸡还是先有蛋的情况。
- 入侵检测 - 拥有一个良好的系统，如果您遭到黑客攻击，该系统很有可能发出警报。如果您的密码数据遭到泄露，您希望在出现任何威胁之前尽早告知用户。
- 审核日志 - 对谁在系统上做了什么有非常好的记录 - 特别是在您的密码附近。虽然您可以创建一个非常出色的系统，但特权用户做坏事(或愚蠢的事情)的威胁与外部威胁一样严重。典型的高端审核系统以高权限用户无法查看或篡改的方式跟踪高权限用户行为 - 相反，还有第二个“审核员”帐户，仅处理审核日志，不处理其他任何事情。
这是系统安全性高点的一大亮点。我的一般观点是 - 如果您认真保护用户密码，您就不能只考虑数据。仅加密密码可能不足以真正保护用户并维护信任。
解决这个问题的标准方法是考虑开发成本与保护成本。如果这两种成本对于该功能的值(value)来说都太高，那么您就有一个很好的迹象表明您不应该费心这样做......
关于security - 当仍需要访问明文时安全存储密码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5099855/