Question

我正在开发一个Windows桌面程序。该程序将连接到远程SQL服务器。它有3层架构。因此，该解决方案包含几个ClassLibraries以及一个主Windows窗体应用程序。我觉得使用像这样的连接字符串是不安全的：

 string connStr = "Data Source=94.xx.xxx.xx; Initial Catalog=xxxxx; User Id=xxxxx; Password=xxxxx";

这样使用是否安全？有人可以反编译“.exe”文件并访问此连接字符串吗？我知道我可以使用app.config文件。但我无法导入“ConfigurationManager”，无法使用“ConfigurationManager.ConnectionStrings [”xxx“]。ConnectionString.ToString（）;”码。除此之外，它也感觉不安全。我认为，最佳做法是加密连接字符串。我找到了一个例子：

http://www.codeproject.com/Articles/18558/Encrypting-windows-application-connection-strings

但它使用旧版本的Visual Studio。我无法弄清楚如何添加“安装项目与包含项目的主要输出的自定义操作”。

在3层架构的Windows窗体应用程序中是否还有其他方法可以安全地使用连接字符串？

PS：我正在使用Visual Studio Express 2013 for Windows Desktop

Answer 1

无法在计算机上隐藏连接字符串。任何相反的建议都是蛇油。加密无济于事。您运行应用程序的计算机上的本地管理员（轻松）会破坏您提出的所有可能方案。无论您尝试设计保护措施多么花哨，本地管理员始终都可以访问您的本地加密密钥。

使用嵌入式名称和密码部署连接到公共SQL Server的应用程序是徒劳的，无论您如何尝试隐藏名称和密码，都是徒劳的。

更好的立场是部署使用用户输入的名称和密码连接的应用程序（登录对话框）。显然，每个应用程序用户都使用不同的SQL用户/密码。但是，由于每个用户的名称/密码维护都无法管理，因此在任何中型部署中也会崩溃。

一个不错的解决方案是使用集成身份验证，但这只适用于域（即公司）。如果您的应用程序要在域（或林）中分发，即。在公司中，集成身份验证是正确的方法。

如果您将应用程序分发给公众，并且您的应用程序需要打电话回家＆＃39;并通过公共互联网连接到SQL Server，然后您需要返回绘图板。它永远不会工作，安全问题是无法解决的。您必须更改应用程序连接到服务接口（REST，SOAP）并通过首选身份验证方法（表单，oauth）对其进行身份验证。毋庸置疑，如果您使用直接SQL连接（EF，Linq，ADO.NEt）对您的应用进行编码，那么这一切都将耗尽，您必须从头开始新的应用。

Answer 2

您必须打开VS命令提示符并编写下面提到的命令。

用于加密

aspnet_regiis -pe connectionStrings -app /VirtualDirectioryPath -prov DataProtectionConfigurationProvider

或

ASPNET_REGIIS -pef "connectionStrings" "D:\IIS\admin.mySite.com"

解密

aspnet_regiis -pd connectionStrings -app /VirtualDirectioryPath

或

ASPNET_REGIIS -pdf "connectionStrings" "D:\IIS\admin.mySite.com"

加密连接字符串

2 个答案: