我正在做一个windows桌面程序。这个程序将连接到远程SQL服务器。它有一个三层架构。因此，该解决方案包含几个类库以及一个主要的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。我不知道如何添加一个"带有包含项目主要输出的自定义操作的设置项目"。
有没有其他的方法来安全地使用连接字符串在一个三层架构的Windows窗体应用程序?
PS:我正在使用Visual Studio Express 2013 for Windows Desktop
不可能在机器上隐藏连接字符串。任何相反的建议都是骗人的。加密也无济于事。您提出的所有可能的方案都将(很容易)被运行您的应用程序的机器上的本地管理员挫败。无论你把保护设计得多么花哨，本地管理员都可以访问你的本地加密密钥。
部署使用嵌入式名称和密码连接到公共SQL Server的应用程序是注定徒劳的练习，无论您如何尝试隐藏名称和密码。
更好的做法是部署使用用户输入的名称和密码(登录对话框)进行连接的应用程序。显然，每个应用程序用户使用不同的SQL用户/密码。但这在任何中等规模的部署中也会崩溃，因为每个用户的名称/密码维护变得无法管理。
一个体面的解决方案是使用集成身份验证，但这只适用于一个域中(即。一个公司)。如果您的应用程序要分布在一个域中(或林中)，即。在公司中，集成身份验证是正确的方法。
如果你将你的应用程序分发给公众，你的应用程序需要"打电话回家"并通过公共互联网连接到SQL Server，那么你需要回到绘图板。它永远不会起作用，安全问题是不可能解决的。您必须更改连接到服务接口(REST、SOAP)的应用程序，并通过您首选的身份验证方法(表单、oauth)对其进行身份验证。不用说，如果你使用直接SQL连接(EF, Linq, ADO.NEt)来编码你的应用程序，那么这一切都是白费的，你必须从头开始一个新的应用程序。
你必须打开VS命令提示符并写下下面提到的命令。
用于加密
aspnet_regiis -pe connectionStrings -app /VirtualDirectioryPath -prov DataProtectionConfigurationProvider
或
ASPNET_REGIIS -pef "connectionStrings" "D:IISadmin.mySite.com"
用于解密
aspnet_regiis -pd connectionStrings -app /VirtualDirectioryPath
或
ASPNET_REGIIS -pdf "connectionStrings" "D:IISadmin.mySite.com"