【问题标题】:Encrypt connection strings [duplicate]加密连接字符串[重复]
【发布时间】:2014-08-21 18:24:47
【问题描述】:

我正在开发一个 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:我正在使用适用于 Windows 桌面的 Visual Studio Express 2013

【问题讨论】:

  • 但是,实际上在您的应用程序或机器中安全存储某些密钥的唯一方法是根本不存储它们。

标签: c# asp.net encryption connection-string


【解决方案1】:

无法在机器上隐藏连接字符串。任何相反的建议都是蛇油。加密无济于事。您提出的所有可能的方案都将(很容易)被运行您的应用程序的机器上的本地管理员击败。无论您尝试如何设计保护措施,本地管理员始终可以访问您的本地加密密钥。

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

更好的做法是部署一个使用用户输入的名称和密码进行连接的应用程序(登录对话框)。显然,每个应用程序用户使用不同的 SQL 用户/密码。但这在任何中型部署中也会崩溃,因为每个用户的名称/密码维护变得无法管理。

一个不错的解决方案是使用集成身份验证,但这仅适用于域(即公司)。如果您的应用程序要分布在域(或森林)中,即。在公司中,集成身份验证是执行此操作的正确方法。

如果您将应用程序分发给广大公众,并且您的应用程序需要“打电话回家”并通过公共 Internet 连接到 SQL Server,那么您需要回到绘图板上。它永远不会起作用,安全问题是不可能解决的。您必须更改您的应用程序连接到服务接口(REST、SOAP)并通过您首选的身份验证方法(表单、oauth)对其进行身份验证。不用说,如果您使用直接 SQL 连接(EF、Linq、ADO.NEt)来编写您的应用程序,这一切都会付诸东流,您必须从头开始一个新的应用程序。

【讨论】:

  • 幸运的是,我现在只是在设计应用程序。我将尝试 SOAP 方法。如果我错了,请纠正我,我应该为这种方法构建一个 Web 服务,并且该 Web 服务将处理请求?所以我所有的数据访问层都应该去一个网络域? Web 服务应该处理所有数据库查询?
【解决方案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"

【讨论】:

    猜你喜欢
    • 2010-10-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-02-05
    • 2016-02-10
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多