将分布式wpf应用程序的数据库连接字符串保护到具有本地管理员权限的用户的最差最佳选项

Question

我试图阅读有关此问题的不同解决方案，我明白走的路要在很大程度上取决于每个方案。这是一个很好的链接：http://msdn.microsoft.com/en-us/magazine/cc164054.aspx。

我很感激有关此特定情况的一些专家建议。

情景：

带有sql compact数据库的WPF应用程序，该数据库将分发给具有本地管理员权限的客户端。应用程序不能始终依赖Internet连接。没有，除了应用程序本身应该能够访问数据库。那么，最好的情况是什么，或者最不好的情况呢？我的意思是说用户无法获取数据库凭据。

编辑：数据库是引擎默认加密的，并且具有强密码。

选项：

• 使用受保护的配置加密配置文件部分（http://msdn.microsoft.com/en-us/library/89211k9b(v=vs.80).aspx）
  • 使用DPAPIProtectedConfigurationProvider（使用客户端密钥）：
    • 优点：更难掌握钥匙......？或者当用户具有本地管理员权限时可能不会。？
    • 缺点：连接字符串只能在加密字符串的计算机上解密。必须在客户端计算机上加密。应用程序第一次运行时，或者使用MSI安装时使用自定义操作。如果你知道在执行之前必须要查看它们，那么它们都很容易掌握连接字符串。
  • 使用RSAProtectedConfigurationProvider（使用提供的密钥）：
    • 优点：数据在分发时加密
    • 缺点：密钥必须存储在某个地方，并且更容易妥协。??只要用户具有本地管理员权限，可能与DPAPIProtectedConfigurationProvider没有区别。？
• 使用Windows安全性：
  • 缺点：用户可以使用自己的凭据轻松连接到数据库。所以这不是一个选择。
• 数据隐藏：
  • 缺点：通过示例进行逆向工程时，很容易掌握连接字符串。这不是一个独立的选项。
• 其他选择？

我看到很多示例建议使用DPAPIProtectedConfigurationProvider并在第一次执行时加密app.config中的连接字符串，或者在安装过程中使用自定义操作加密。

好吧，我认为最糟糕的选择是使用RSAProtectedConfigurationProvider加密app.config，每次都生成一个自定义RSA密钥（每次使用密钥相同的逻辑）。然后所有这些代码都被混淆了。通过这种方式，app.config可以使用加密的连接字符串进行分发。

我知道凭据仍然可以被破坏，并且在这种情况下无法避免这种情况。这都是关于选择最差的选项。

现在我很感激你的意见......谢谢！

Answer 1

您是对的：您无法阻止确定的本地管理员访问此数据库。

这是我作为一个坚定的用户会做的事情（我过去和其他程序一样）：我会将调试器附加到正在运行的进程并查看内存以找到普通连接字符串（当然我正在简化 - 但它确实有效。）

另一个选择是使用调试器来劫持你的IDbCommand对象来执行任意SQL代码，不需要我找到连接凭据，你的应用程序为我管理连接。

所以它真的归结为：你的用户有多么称职和坚定？你的数据库有多重要？你有多坚定？ 这是经典的黑客权衡：你想用多少努力来阻止你的用户破解你的应用程序，知道最终在技术上可以破解它？

我会做的最低限度：

1. 加密原始连接字符串。你已经涵盖了这一部分。

2. 也许在代码中进行加密而不是依赖内置的app.config部分加密。内置的问题在于它是自我记录的。拥有.net知识的人只要通过阅读它就知道它是如何加密的。通过保护密钥来提供安全性，但是它们实际上不能从本地管理员隐藏。甚至还有一个命令行工具来解密该部分（如果你传递了正确的密钥）！在代码中执行解密使得您使用哪种算法不太明显，并且需要更多工作来实际解密它。 注意：您仍应使用强大的加密提供程序，例如您提到的那些。我不说你应该发明自己的加密密码，而不是隐藏你在程序本身使用的密码而不是配置文件。

3. 对已编译的程序集进行模糊处理。否则，只需在IlSpy等工具中轻松打开它，甚至可以修改它（例如转储普通连接字符串）。

4. 添加一些调试器陷阱以防止将调试程序附加到您的进程。

请注意，对于混合模式程序集（包含本机代码和托管代码的程序集），3和4都会更有效。

这是一个开始。也许其他人会有更多的想法。

---

当然这只是应用方面。嵌入式数据库也应受到适当保护。它应该加密开始。