在散列时将密码存储在数据库中并不适用

Question

Stack Overflow上有很多关于如何存储用户密码的问题，当然一般的建议是散列密码并比较哈希值。

但是，假设您正在构建人们在自己的环境中部署的收缩包装Intranet应用程序（如SharePoint）。并且假设它需要用户名/密码组合来通过HTTP访问外部服务（不支持依赖API密钥或联合安全性的解决方案）。

在这种情况下，我们无法对密码进行哈希处理，因为我们需要将原始密码传递给我们调用的Web服务。加密将是第二个最佳解决方案，但我们将使用什么加密密钥？如果攻击者破坏了数据库，可能他们可以访问用于加密数据的任何密钥？

如果您真的需要获得存储密码的纯文本版本，那么您将如何以最安全的方式解决问题？

Answer 1

您可以从用户的密码生成加密密钥。 （不是他们的外部服务密码 - 他们的服务密码。）由于您没有以明文形式存储密码，因此攻击者破坏了您的数据库将无法解密密码。不利的一面是，只要您需要外部密码，就必须向他们索要密码（用于您的服务）。

Answer 2

这实际上是一个非常有趣的问题。我会加入。

存储时应加密。无论你怎么看，它都比以纯文本形式存储更好。假设攻击者发现一个sql注入广告转储数据库，他仍然没有持有加密密钥。另一方面，如果他可以访问服务器，他可能也会找到加密密钥。

为了进一步改进，您可以将加密密钥存储在服务器配置中。假设您使用的是Apache，则可以使用SetEnv。

我在我的环境中需要在Apache启动时输入加密密钥，然后将其存储为环境变量，因此密钥实际上并未存储在我的服务器上。

除非您要求用户输入密钥以解密您将100％安全的密码，否则无法使用。

Answer 3

你有问题倒置了。问题不在于如何让消费者“查看”密码;问题是如何让消费者验证身份验证。

在您的实现中提供了一种方法，消费者可以通过该方式提供密码和用户名，并获得是或否。然后，您继续在数据库中存储加密（非散列）密码。