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

乍一看，这可能听起来是一个糟糕的想法，但我的场景是：我有一个Windows服务，它使用用户名身份验证公开了几个WCF端点。自定义验证器将在本地数据库中查找用户的凭据（密码存储为salted SHA-1），或者向另一个服务发出WCF请求以验证密码。（用户对象上有一个枚举，可以是内部的，也可以是外部的，指示要使用哪个身份验证源）

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

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

该服务将在物理和网络安全性良好的内部服务器上运行。将明文密码存储在缓存中而不是存储哈希版本是一种可接受的做法吗？在这种情况下，我的风险似乎是攻击者转储进程内存并获取密码。如果我认为风险是可以接受的，我还有什么理由避免在内存中使用明文密码吗？

---

如果我选择使用明文密码，我认为SecureString可以在一定程度上限制我的风险。使用SecureString（实现它似乎非常迂回）值得吗？我很清楚持续存储未散列密码的风险，但我不确定对明文密码的易失性存储的共识是什么。

SecureString使用加密内存，因此这可能会比每次自己进行散列提高性能。但您必须在您的环境中分析它

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

以下是我的建议： 考虑密码泄露的后果——基本上，黑客拥有密码有多少价值（$$或$$）？如今，大多数安全问题都来自财务激励。相对而言，这些家伙比纯粹的故意破坏行为更为严重

现在将其与安全性可能以完全不同的方式受损的可能性进行比较，即SQL注入或致电用户“验证其帐户”。如果两个密码的$value很高，并且没有其他方法获得它们，那么也许您应该继续加密它们（现在您已经证明了更强大服务器的成本是合理的！）。然后确保加密密钥的安全——一旦黑客拥有了你的服务器，这些密钥很可能和程序内存一样容易访问

另一方面，如果该值较低，并且有其他可能的漏洞可用（而且经常存在），您可以提出合理的理由，认为黑客不值得花时间破坏服务器并转储内存

祝你好运

该服务将在物理和网络安全性良好的内部服务器上运行

---

只要从现在到永远（或者下一个补丁，它总是第一个出现）都是这样，将缓存的密码以纯文本的形式存储在ram中就可以了。如果您将整个密码数据库存储在ram中（比如说您的持久存储速度太慢），我认为将它们存储为安全字符串会更好，但由于您最多只存储一分钟的几个密码，我看没问题。

除非你告诉我获得密码值100万美元，否则我可能会被诱惑：）非常好的分数。经过一些讨论，我们意识到WCF自定义用户名身份验证无论如何都是以明文形式传递密码的，因此在任何给定的时间点内存中都有明文密码（在身份验证之间以及当这些变量被GC’ed时）。因此，缓存它们（特别是过期的）并不会增加我们的风险。感谢这些优点，我在讨论中提出了它们，这帮助我们得出结论，在我们的环境中这是可以接受的。