缓存WCF服务内存中的明文密码

Question

这可能听起来像是一个可怕的想法乍一看，但这里是我的情况：我有一个Windows服务，使用用户名认证公开几个WCF端点。自定义身份验证器将在本地数据库中查找用户的凭据（密码存储为盐渍SHA-1），或者它将向另一个服务发出WCF请求以验证密码。 （在User对象上有一个枚举，可以是Internal或External，指示使用哪个验证源）。

我发现执行查找+哈希检查或使WCF调用对我的服务的每个请求都很昂贵，所以我想缓存用户名/密码信息。缓存中的每个项目都有一个生命周期，例如，如果缓存中的项目的时间为60秒，则在下一次请求时，身份验证器将根据原始源代替缓存验证凭据，然后进行更新。

对于本地数据库，我可以简单地将用户名/ SHA1对存储在字典中，并且在来自“内部”用户的每个请求中，我只需重新提供散列提供的密码并进行比较。对于“外部”用户，我只会将明文密码提交给验证器，所以我将它放在哈希中并将其存储为缓存的一部分。尽管这肯定节省了数据库请求或远程服务调用的开销，但我仍然必须每次都执行哈希操作。

有问题的服务将运行在具有良好物理和网络安全性的内部服务器上。将明文密码存储在缓存中而不是存储散列版本是否可接受？在这种情况下，我的风险似乎是攻击者倾倒进程内存并获取密码。如果我认为风险可以接受，是否还有其他原因，我应该避免在内存中使用明文密码？

如果我选择使用明文密码，我认为SecureString可以在一定程度上限制我的风险。使用SecureString（实现它看起来非常迂回）是否值得遇到麻烦？我很清楚持久存储密码的风险，但我不确定共识似乎是什么在易变的明文密码存储上。

Answer 1

SecureString使用加密的内存，所以这可能会提高每次执行散列时的性能。但是你必须在你的环境中进行配置。

至于在存储器中存储普通密码的风险，这不是在这种情况下可以回答的问题。我只能说，是的。因为这是出于各种原因适合我的情况。但那不会和你的一样。

以下是我的建议： 考虑密码泄漏的影响 - 基本上多少钱（$或$$$？）给黑客拥有密码？目前大多数安全问题都来自财务激励。相对而言，纯粹的破坏行为被这些家伙抛弃了。

现在将其与以完全不同的方式（即SQL注入或打电话给用户以“验证他们的帐户”）的安全性进行比较的可能性进行比较。如果几个密码的$值很高，并且没有其他方法来获取它们，那么也许你应该继续对它们进行加密（现在你已经证明了更强大的服务器的成本！）。并确保你保护密钥 - 一旦黑客拥有你的服务器，这些密钥就像程序存储器一样容易访问。另一方面，如果价值低，并且还有其他可能的利用方式（通常存在），那么可以合理地提出一个合理的观点，认为黑客的时间不利于服务器和转储记忆。

祝你好运。

Answer 2

有问题的服务将运行在具有良好物理和网络安全性的内部服务器上。

只要从现在开始直到永恒（或下一个补丁，永远都是第一个）都是正确的，将缓存的密码存储在内存中就像纯文本一样好。如果你将整个密码数据库存储在ram中（比如说你的持久存储速度太慢），我认为将它们存储为安全字符串会更好，但由于你只能存储多个密码至多1分钟，所以没有问题。