创建数据库连接时硬编码凭据的风险是什么?

时间:2016-12-16 10:37:59

标签: security credentials

嗨安全意识的人,

我最近使用静态代码分析工具扫描了我的应用程序,其中一个高严重性调查结果是用于创建连接的硬编码用户名和密码:

dm.getConnection(databaseUrl,"server","revres");

为什么扫描仪认为这是应用程序的风险?我可以看到一些缺点,例如如果密码被破坏则无法轻易更改密码。从理论上讲,有人可以对二进制文件进行逆向工程以学习凭据。但我没有看到将凭证存储在配置文件中的优势,除非它们是加密的,否则它们很容易找到和读取。如果我加密它们,我将用加密密钥解决同样的问题...

还有更多我看不到的风险吗?或者我应该使用完全不同的方法? 非常感谢你。

4 个答案:

答案 0 :(得分:0)

代码中嵌入的固定密码对于每个安装都是相同的,并且任何有权访问源代码或二进制文件(包括安装介质)的人都可以访问。

从文件读取的密码对于每个安装可以是不同的,并且只有那些能够读取密码文件的人才知道。

通常,您的安装程序将为每个站点生成一个唯一的密码,并将其安全地写入您的应用程序要读取的文件。 (通过"安全",我的意思是使用@Path("/api/reservations") 来防止符号链接攻击,并且在其他人可以打开之前正确选择文件位置和权限。)

答案 1 :(得分:0)

这是一个有趣的问题,我可以为您提供.Net应用程序的示例(因为您没有指定使用的运行环境/技术)。虽然我的猜测是Java?我希望这仍然有用并帮助你。

我的主要建议是阅读这篇文章并从那里开始:Protecting Connection information - MSDN

以下是介绍working with encrypted configuration files here

的页面

我已经看到这解决了使用加密配置文件和Windows身份验证。我认为以一个用户身份运行您的应用程序将被授予对相关存储过程等的访问权限(尽可能少,例如最小权限原则)以及文件夹访问等等,这是一条很好的途径。

我建议使用这两种技术,因为这样您就可以为IIS提供相关的本地文件夹访问权限,并在SQL等中拆分您的用户访问权限。这也有助于更好的审核!

这取决于您的应用需求。我可以说通过配置文件或环境用户帐户进行配置的主要原因是,当您将应用程序发布到生产环境时,您的开发人员不需要访问生产用户帐户信息,而只需使用本地/系统测试/ UAT凭证。

当然,它们也不会以明文形式存储在您的源代码管理中,如果您在GIT这样的私有分布式网络中托管,则可能意味着这可能会受到影响而黑客可以访问凭据。< / p>

答案 2 :(得分:-1)

我认为这取决于您的源代码或编译代码的可访问性/安全性。开发人员通常在他们的开发盒上有代码的副本,这些代码通常不如生产服务器那么安全,因此更容易被黑客攻击。通常,在开发框上配置测试用户/ pw,并且在生产中,“真实”pw存储在更安全的配置文件中。是的,如果有人入侵服务器,他们可以很容易地获得凭据,但这比在大多数情况下进入开发箱要困难得多。但就像我说的那样取决于。如果只有一个开发人员,他们有一个超级安全的机器,他们的代码的回购也是超级安全的,那么没有有效的区别。

答案 3 :(得分:-1)

我所做的是最初向最终用户询问凭据,然后加密并将其存储在文件中。这样,我就不知道他们的连接细节和密码是开发者。密钥是一个哈希二进制文件,我通过在两者之间调用ekstra字节来存储它。想要破解它的人应该找出所使用的算法,密钥和向量长度,它们的位置以及保持值的字节序列的起始端位置。一个天才,他也会对我的代码进行反向工程以获取所有这些信息(但是直接破解最终用户的凭证可能更容易)。