如果我有一个存储的密钥文件用于解密进入我的应用程序的加密输入，并且我将该密钥文件存储为嵌入式资源，以便在部署时将其嵌入到程序集中，那么对于某人来说有多难对应用程序进行反向工程并检索密钥文件？
此外，该应用程序是通过ClickOnce“仅限在线”模式部署的，我想这也会使逆向工程变得更加困难？ （我不完全确定ClickOnce的工作方式，但在仅在线模式下运行应用程序后，我无法在本地计算机上找到dll /程序集...）。
更新 由于Ralf在他的评论中基本上回答了下面的主要问题（回答：它根本不安全），这里有更多信息，以便知识渊博的人可以提出更好的安全模型。
加密将用于加密我的应用程序的登录密码，以便在SSO设置中使用（用户将首先登录到其他系统，然后通过单击链接将能够直接打开我的申请，无需输入他们的登录详细信息）。
加密数据将作为base-64字符串URL参数发送到将启动我的Click-once应用程序的链接中。
我还将开发一个应用程序，它将为URL参数创建加密数据（澄清：不是用户将为SSO登录的第一个应用程序，我只会创建一个小工具，将纯文本密码转换为加密的base64字符串。）
它只是一个内部应用程序，因此防弹安全性并不重要，部署的简易性更为重要，但了解最佳实践和可用的不同选项会很好。
答案 0 :(得分：0)
只要可以启动应用程序，文件就必须在计算机上的某个位置。你只需要知道去哪里找。逆向工程可能很丑，但总是可行的。计算机必须能够理解他应该做什么，所以你只需要提供正在寻找的信息。因此，应用程序的安全性决不应该取决于逆向工程的难度！我相信安全的应用程序应该是开源的。
您可能需要一个不同的安全模型。这里重要的是你知道你想要保护数据的是什么。如果您只是想知道数据是由服务器而不是其他人（中间人攻击）发送的，那么您可以使用数字签名。 如果您不希望任何人读取服务器和客户端之间发送的任何数据，您应该使用某种ssl实现来创建加密通道。然后，您只需要注意服务器的公钥不会在客户端上更改。这可以通过官方CA的证书来完成，但不幸的是，这些通常不是免费的。
答案 1 :(得分：0)
无论是明文还是加密，您都不想存储密码。当您获得密码时，您应该做的就是将其传递给您的服务器应用程序，在那里您将其与数据库中密码的盐渍哈希进行比较。即使您不认为安全性非常重要，您也需要注意密码，因为人们经常在不同系统中重复使用密码。我知道他们不应该这样做。
如果要实施单点登录（SSO），请在服务器端创建一个令牌，然后将其传递回客户端，加密或签名（HMAC是签名的好选择） 。这是一个难以伪造的令牌，因为您需要知道HMAC的加密密钥或共享密钥，并且该数据仅在您的服务器上已知。因此，您拥有自己的SSO，并且所有涉及SSO的数据都在服务器上进行管理，因此不存在数据泄漏或欺骗的可能性。