我有一个.NET服务器应用程序，它必须存储无法散列的密码，因为我使用的某些API需要纯文本密码。存储无法在服务器应用程序中进行散列的密码
这些密码也可以作为系统配置的一部分导出和导入到应用程序的另一个服务器实例或用于备份目的。
加密的数据肯定需要由其他服务器上的应用程序实例读取，除了它从中导出。
什么是最安全的方式来实现这一点，没有太多的麻烦用户和丢失/不可用的加密密钥数据丢失的最小风险？
编辑
我期待更多的像细节：
...没有使用哪种加密算法。
编辑II
我要补充，这个应用程序将被分发到客户自己的服务器上运行。它是一个客户端/服务器应用程序。存储的密码仅供我们的应用程序用于传递到外部API方法。我们不会将它们用于其他任何事情。
主要问题是系统配置导出为XML备份或移动到不同的机器。这是我们想要保护它们的地方，但也尽可能让用户更容易和灵活。
后在你描述你所寻找的，以下是一些建议编辑 -
如果您使用用户密码作为密钥或种子进行，该密钥可以存储在数据库或即使是与用户关联的CSV文件。 完成之后，接下来的问题是，什么更好 - 每次安装都生成一个唯一的密钥或具有通用应用程序密钥。 其实，有一个通用的应用程序密钥是一个坏主意，有几个原因 - 1.如果它被破解一次，所有您以前的交流也可能被破解。 2.当加密的密码可以重播时，它容易发生重播攻击。 3.你应该有意识地不断改变这个关键。
因此，在任何一天，生成一个唯一的密钥是一个更好的主意。我认为你应该考虑Diffie-Hellman密钥交换。我认为这将解决你的大部分问题。 D-H密钥交换的概念是，您使用您自己的用户提供的密钥来建立通信的唯一（每个事务）密钥。关于这种方法最好的部分是，实际的密钥永远不会显示，并且您可以基于相同的旧种子/密钥每次生成新的密码。
看看它。
那么如果你只是在寻找一个强大的算法，你可能会比使用TripleDES更糟糕。它可能是32岁，但仍然非常强大。
如果你想要一些新的东西，AES（原来Rijndael）也很好。
您可能想要比较每个的性能，以查看最适合您的设备。
说到加密，密钥就像硬件加密狗。用你的生命保护它。
你在使用什么服务器？大多数现代RDMBS都带有加密功能，可以在休息时为您处理数据加密，无需外部密钥。这将至少保护服务器中的数据...
该应用程序目前使用一个内部的VisaDB数据库，但它将在未来支持更多的外部数据库。配置在导出时会保存到XML文件中，在这种情况下我最担心的是密码。 – 2009-06-19 14:50:55
你可以让你的程序对它们进行加密，这样你的客户可以解密它们，你的客户也可以解密它们。在编程使用它们时，密码只能是纯文本。
其实，一个好方法是使用用户输入的密码作为种子/密钥来生成动态更强的密码。许多服务器一直都在这样做。这给你几个好处。 1.对用户没有麻烦。 2.您可以将用户密码保存为文本文件。 3.机器生成的密码强于人类提供的密码。 4.您可以使用相同的种子生成新的密码，从而使您的协议更加适合重播攻击。
试一试。
我们使用不对称的公钥加密存储信用卡信息。许多服务器都有用于加密信用卡的公钥。只有我们的cc网关应用程序具有用于解密和处理付款的私钥。私钥作为证书安装在生产服务器上。
由于您正在存储密码，因此您应该仍然有一个用于快速用户身份验证的哈希。
恕我直言：当我们谈论的类似密码加密，我甚至不会考虑做一个性能比较，除非你正在运行的enrypt /在286 解密代码对大量数据进行密码处理？当然。短弦？巴阿。 – Yoopergeek 2009-06-19 14:49:14