保持密码可configuration的最佳方式是什么?不要让读者随便使用这些密码?

我有一个数据库,许多不同的客户端应用程序(一些Web服务,一些Java应用程序和几个networking应用程序)连接到。 并不是所有这些都在Windows上运行(可惜的是,否则这将使这只是一个简单的答案问题,只是启用数据库连接的Windows身份validation)。 目前,密码存储在系统周围的各种configuration/属性文件中。 理想情况下,只有支持人员才能访问正在运行文件的服务器,但是如果其他人可以访问其中一台服务器,则他们将拥有足够的数据库权限,以便按照现在的情况获得相当数量的数据。

我的问题是,保持密码可configuration的最好方法是什么?

编辑为了澄清,DB服务器是Windows Server 2003,运行MSSQL 2005。

PS:我没有看到这个重复的任何问题,但如果有的话,请随时closures这个问题。

我假设你想隐藏观察者的密码。 如果他们是邪恶的,钢铁般的观察者可以访问连接的机器上的所有源代码,那么他们可以通过一些逆向工程来获得密码。

请记住,您不需要为每个不同的客户端使用相同的保护。 几个步骤: –

  1. 为访问数据库的不同系统创build不同的数据库帐户
  2. 限制对数据库的访问,只使用内置的数据库GRANT
  3. 在数据库的密码pipe理器类中存储三重DES(或其他)密钥。 使用它来解密属性文件中的encryption值。

我们也考虑过应用程序在启动时提示input密码,但没有实现,因为它看起来像一个痛苦,你的操作人员需要知道密码。 这可能不太安全。

我们假设以下常见的情况:

  • 您在所有环境中使用相同的代码库,并且您的代码库具有每个环境的数据库密码。

  • 可以访问生产应用程序服务器的人员(系统pipe理员,configurationpipe理员)可以知道生产数据库密码,而不需要其他人员。

  • 您不希望任何有权访问源代码的人知道生产密码是什么。

在这种情况下,您可以将生产密码encryption并存储在应用程序的属性文件中。 在应用程序中,您可以包含一个类,该属性从属性文件中读取密码,并在将其传递到数据库驱动程序之前将其解密。 但是,用于解密密码的密钥和algorithm不是源代码的一部分,而是在运行时作为系统属性传递给应用程序。 这从应用程序源代码中解密了密钥的知识,任何有权访问应用程序源代码的人将不能再解密密码,因为他们无权访问应用程序的运行时环境(应用程序服务器)。

如果你正在使用Java,请看一下这个更具体的例子。 这个例子使用Spring和Jasypt。 我有信心,像这样的东西可以外推到其他环境,如

在我以前的工作场所,我们曾经有一个系统,所有密码都被encryption(使用三重DES或当时使用的任何密码)。 密码通常存储在属性文件中(这是在Java系统中)。

当需要更改密码时,我们可以简单地使用“!plaintext”作为值,然后我们的代码会加载它,对它进行encryption,并将encryption值存储回属性文件中。

这意味着可以在不知道原始值是什么的情况下更改密码 – 不确定这是否是您要求的那种东西!

这听起来好像没有简单的答案(因为连接的应用程序types不同),实际上,我看到的唯一问题是Java应用程序,它似乎直接连接到数据库。 那是对的吗?

如果是这样,这是你可以做的:

1)更改任何直接连接到数据库的客户端应用程序以通过服务。 (如果他们必须直接连接,那么至less让他们从服务“获取密码”的第一步,然后他们可以直接连接)。

2)将密码存储在web.config文件中(如果您select执行.Net Web服务),然后encryption文件的“连接string”部分。

不要使用密码,服务器到服务器的身份validation通常可以通过使用密钥文件或客户端证书或除密码以外的其他方式执行。

您可以使用可逆的encryptionalgorithm,例如Blowfish来存储密码,作为权宜之计。 应该有一些免费的图书馆,你可以用它来构build你需要这个访问的所有程序。

布鲁斯·施奈尔关于河豚的页面

维基百科有关河豚的文章

对于java的东西,如果你正在使用应用程序服务器,看看你是否可以定义一个数据源,你的应用程序可以使用JNDI获取数据源。 这样,pipe理数据源(包括连接细节)由应用程序服务器处理,而您的应用程序代码所要做的就是要求数据源。

NTLM身份validation或基于LDAP的(Active Directory)身份validation应该可以使用一点点努力。 这将允许您跨应用程序使用您的“Windows身份validation”。

这对您的操作人员来说可能意味着一点点迁移,但是对于一组应用程序来说,SSO是很好的。

是的,我必须同意存储(盐渍)哈希值的选项。 我会build议存储在数据库中的密码的SHA256散列(腌制)。 另外不要忘记执行安全的密码规则。

使用encryption不是一个好主意。 如果有人破坏密钥,他可以解密密钥。 使用含盐的散列algorithm存储paswords。 散列algorithm是一种不可逆的方法。 但他们很容易受到字典攻击,所以使用盐(concatane纯文本有一些长而冗长的哈希值)。 它也保护数据库免受内部攻击。