3

我曾尝试阅读有关这方面的不同解决方案，并且我知道要走的路在很大程度上取决于每个单独的场景。这是一个很好的链接：http: //msdn.microsoft.com/en-us/magazine/cc164054.aspx。

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

设想：

带有 sql 紧凑型数据库的 WPF 应用程序，该数据库将分发给具有本地管理员权限的客户端。该应用程序不能一直依赖互联网连接。没有，除了应用程序本身应该能够访问数据库。那么，最好的情况是什么，或者最坏的情况是什么？我的意思是这样用户就无法获得数据库凭据。

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

选项：

  • 使用受保护的配置加密配置文件部分 ( 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 可以与加密的连接字符串一起分发。

我知道凭据仍然可能被泄露，并且在这种情况下无法避免 100%。一切都是为了选择最差的选项。

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

4

1 回答 1

3

你是对的：你不能阻止一个确定的本地管理员访问这个数据库。

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

另一种选择是使用调试器劫持您的 IDbCommand 对象来执行任意 SQL 代码，我无需查找连接凭据，您的应用程序会为我管理连接。

所以它真的归结为：你的用户有多大的能力和决心？你的数据库有多重要？你有多大的决心？这是典型的黑客权衡：你想在这方面付出多少努力来阻止你的用户破解你的应用程序，知道最终在技术上总是有可能破解它？

我会做的最低限度：

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

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

  3. 混淆编译的程序集。否则很容易在 IlSpy 等工具中打开它，甚至修改它（例如转储普通连接字符串）。

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

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

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

当然，这只是应用方面。嵌入式数据库也应该得到适当的保护。一开始就应该加密。

于 2013-06-02T22:38:29.733 回答