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