这不是通常的问题“存储纯文本用户的密码是否安全？”。不，这不安全，我们都知道。存储密码以便与另一个系统进行身份验证
我正在写一个小程序应针对外部系统进行身份验证，以做一些东西，唯一可用的身份验证方法是通过用户名和密码。它用于人类，不能改变。
有可以访问我的应用程序，每一个被单独认证多个用户，但他们所有的“份额”反对外部系统，在理想情况下是由应用程序透明管理，相同的验证数据。
“哑巴”解决方案是将用户名/密码以纯文本，并使用它进行认证，但显然这不是安全的。密码可以加密，但如果有人闯入系统会怎么样？
可能的解决方案：使用DPAPI透明地加密/解密密码（甚至可能是用户名）。这是一个好主意吗？这安全吗？怎么样设置多台机器（机器间加密兼容）？
您有任何其他建议吗？
DPAPI通常不能用于Web农场 - 密钥存储区特定于计算机。您没有指定某些用户是否共享一组凭据，而另一用户共享另一组凭据。如果所有用户都共享同一组凭据，请将其存储在web.config中并完成。使用web.config文件上的配置加密API或简单ACL来保护凭据。
如果不同的用户有不同的第三方系统的凭据，我会保存凭证与用户，使用用户密码的哈希+盐作为加密密钥。然后，即使恶意用户获得您的数据库，他们也必须能够在尝试破解第三方密码之前先解密用户的密码。这样做会增加一层难度。
添加用户脚本需要知道当然的凭证.. – Will 2009-11-03 07:25:23
使用用户密码哈希（加上盐）进行加密的问题在于，在设置之后很难添加新用户，因为您需要其他人的密码（例如添加用户的管理员）。另外，如果用户更改密码，则必须重新加密她的外部系统凭证的“副本”。这可能是一个可行的解决方案，虽然有点复杂。 – 2009-11-03 08:39:02
@Dario我不确定我是否理解复杂性。鉴于OP，我假设用户在设置其初始帐户（或首次访问它）后提供了第三方凭据。考虑到用户的密码在那时可能已经以散列形式可用，使用所述散列+盐来加密由用户提供的任何凭证将是微不足道的。是的，每次用户更改主密码时都必须重新加密证书，但这似乎并不罕见。 – Chris 2009-11-03 16:10:53
请记住，DPAPI密钥位于用户级别。除非您要为每个用户设置和存储单独的凭证集副本，否则DPAPI不会对您有任何好处。唯一真正安全的方法是使用“受信任的子系统”模式，其中您的Windows服务以某个用户身份运行，受保护的数据存储在该用户的HKCU配置单元中，并使用其DPAPI密钥进行加密。它执行所有需要代表用户进行身份验证的操作，并且用户名/密码不会加载到用户的进程中。即使如此，如果用户是管理员，他们仍然可以在技术上通过调试服务过程来获取用户名/密码。
的真正安全的方式做这将是做同样的事情，但使用的远程Windows凭据的用户验证到需要代表用户的动作的远程服务器。真的只是取决于用户名/密码的安全性。
您需要保持纯文本用户名和密码可用于登录到外部系统。您可以尝试自己加密此文件，然后以某种方式在应用程序中隐藏密钥。
然而，它可能是你的操作系统（例如Windows操作系统）提供保护的文件和其可能的，那些是由经验丰富的专家实施的方式 - 这是很难推荐的投资时间滚动自己！
因此，最好的方法是以纯文本形式存储您的凭据，并依靠操作系统来保护文件，例如
考虑如何机器/服务“原木”加密主目录如果这意味着无人看管，则需要启动启动。
这个问题本身在安全免责声明中涵盖，所以这一点不需要费力。
我认为DPAPI可能是你最好的选择。我不明白你对web农场的意思，尽管... – 2009-11-03 06:57:29
我不确定这是否正是你想要的，但是像DBM等哈希解决方案如何使用？散列用户的密码以进行存储，并在进行身份验证时，散列它们提供的密码并将其与现有散列进行比较。这是一种常用的存储密码的方式。 P.S. - 根据你想要/需要的安全级别，我肯定会推荐腌制你的哈希以避免彩虹表类型的攻击。有关Microsoft长期以来如何使用无残留哈希存储用户密码的文章，请参阅最新一期的“2600”。 – 2009-11-03 07:01:00
@Bob：不是什么被问到！他需要提供密码，因为他将密码发送给外部系统。他正在对别人进行身份验证，而不是对他的系统进行身份验证。 – 2009-11-03 07:03:40