这不是常见的问题“存储纯文本用户的密码是否安全？”。不，这不安全，我们都知道。
我正在编写一个小应用程序，它应该针对外部系统进行身份验证以执行某些操作，唯一可用的身份验证方法是通过用户名和密码。它是为人类设计的，无法更改。
有多个用户可以访问我的应用程序，并且每个用户都单独进行身份验证，但是他们都针对外部系统“共享”相同的身份验证数据，理想情况下，这些数据由应用程序透明地管理。
“愚蠢”的解决方案是以纯文本形式存储用户名/密码并将其用于身份验证，但显然这并不安全。密码可以加密，但如果有人闯入系统怎么办？
可能的解决方案：使用 DPAPI 透明地加密/解密密码（甚至可能是用户名）。这是一个好主意吗？这安全吗？多台机器的设置如何（机器之间的加密兼容）？
你有什么额外的建议吗？
DPAPI 通常不能用于网络场 - 密钥存储是特定于机器的。您没有指定某些用户是否共享一组凭据而另一个用户共享另一组凭据。如果所有用户共享同一组凭据，请将其存储在 web.config 中并使用它。使用配置加密 API 或 web.config 文件上的简单 ACL 保护凭据。
如果不同的用户具有不同的第三方系统凭据，我会将凭据与用户一起存储，使用用户密码的哈希 + 盐作为加密密钥。然后，即使恶意用户获取了您的数据库，他们也必须能够首先解密您的用户密码，然后才能尝试破解第三方密码。盐增加了这样做的难度。
请记住，DPAPI 密钥位于用户级别。除非您要为每个用户设置和存储凭据集的单独副本，否则 DPAPI 对您没有任何好处。唯一真正安全的方法是使用“受信任的子系统”模型，您可以在其中以某个用户身份运行 Windows 服务，并将受保护的数据存储在该用户的 HKCU 配置单元中，并使用其 DPAPI 密钥进行加密。它代表用户对需要身份验证的系统执行所有操作，并且用户名/密码不会加载到用户的进程中。即使这样，如果用户是管理员，从技术上讲，他们仍然可以通过调试服务进程来获取用户名/密码。
真正安全的方法是做同样的事情，但远程使用 Windows 凭据向远程服务器授权用户，该服务器代表用户采取行动。真的只是取决于用户名/密码需要有多安全。
您需要保留可用于登录外部系统的纯文本用户名和密码。您可以尝试自己加密此文件，然后在您的应用程序中以某种方式隐藏密钥。
但是，您的操作系统（例如 Windows）很可能确实提供了保护文件的方法，并且这些方法很可能是由经验丰富的专家实施的 - 很难建议您花时间自己动手！
因此，最好的方法是将您的凭据存储为纯文本并依靠操作系统来保护文件，例如
如果这意味着无人看管，则需要考虑机器/服务在启动时如何“登录”。
该问题本身已包含在安全免责声明中，因此这一点无需费力。