保护属性文件中的密码

我有一个连接到数据库的Java应用程序。
数据库的用户名和密码存储在属性文件中。
避免将属性文件中的密码以明文forms存储,同时仍然保留允许用户更改密码的选项的常用做法是什么?
这里的主要动机是防止有人在pipe理员编辑属性文件时查看pipe理员的肩膀并看到密码。
我在这里读到,有一个build立在C#中的方式。
了解Java,我不期望find一个内置的解决scheme,但我想听听别人在做什么。
如果我没有find任何好的select,那么我可能会用一个常量密码进行encryption,这个密码将保存在代码中。 但我讨厌这样做,因为感觉不对。

编辑2012年12月12日看起来像没有魔法,我必须将密码存储在代码或类似的东西。 最后,我们实现了一个与Jasypt非常相似的东西,就是其中一个答案中提到的Jasypt。 所以我接受了Jasypt的答案,因为它是最接近确切答案的东西。

在这里输入图像说明

Jasypt提供了org.jasypt.properties.EncryptableProperties类,用于加载,pipe理和透明地解密.properties文件中的encryption值,允许在同一个文件中混合encryption值和非encryption值。

http://www.jasypt.org/encrypting-configuration.html

通过使用org.jasypt.properties.EncryptableProperties对象,应用程序将能够正确读取和使用.properties文件,如下所示:

datasource.driver=com.mysql.jdbc.Driver datasource.url=jdbc:mysql://localhost/reportsdb datasource.username=reportsUser datasource.password=ENC(G6N718UuyPE5bHyWKyuLQSm02auQPUtm) 

请注意,数据库密码是encryption的(事实上,任何其他属性也可以encryption,无论是否与数据库configuration有关)。

我们如何读取这个值? 喜欢这个:

 /* * First, create (or ask some other component for) the adequate encryptor for * decrypting the values in our .properties file. */ StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor(); encryptor.setPassword("jasypt"); // could be got from web, env variable... /* * Create our EncryptableProperties object and load it the usual way. */ Properties props = new EncryptableProperties(encryptor); props.load(new FileInputStream("/path/to/my/configuration.properties")); /* * To get a non-encrypted value, we just get it with getProperty... */ String datasourceUsername = props.getProperty("datasource.username"); /* * ...and to get an encrypted value, we do exactly the same. Decryption will * be transparently performed behind the scenes. */ String datasourcePassword = props.getProperty("datasource.password"); // From now on, datasourcePassword equals "reports_passwd"... 

穷人妥协解决scheme是使用一个简单的多签名方法。

例如,DBA将应用程序数据库密码设置为50个字符的随机string。 TAKqWskc4ncvKaJTyDcgAHq82X7tX6GfK2fc386bmNw3muknjU

他或她将密码的一半给应用程序开发人员,然后将其硬编码到java二进制文件中。

私人stringpass1 =“TAKqWskc4ncvKaJTyDcgAHq82”

另一半的密码作为命令行parameter passing。 DBA将pass2发给系统支持人员或pipe理员,或者将其input到应用程序启动时间或将其放入自动应用程序启动脚本中。

java -jar /myapplication.jar -pass2 X7tX6GfK2fc386bmNw3muknjU

当应用程序启动时,它使用pass1 + pass2并连接到数据库。

这个解决scheme有很多优点,没有提到的缺点。

你可以安全地把一半的密码放在一个命令行参数中,因为阅读它不会帮助你,除非你是拥有另一半密码的开发者。

DBA还可以更改密码的后半部分,开发人员不需要重新部署应用程序。

源代码在读取时也可以是半公开的,密码不会给你应用程序访问权限。

您可以通过在数据库将接受连接的IP地址范围上添加限制来进一步改善情况。

那么提供一个自定义的N-因素authentication机制呢?

在结合可用的方法之前,让我们假设我们可以执行以下操作:

1)Java程序内部的硬编码

2)存储在.properties文件中

3)要求用户从命令行input密码

4)要求用户从表单中input密码

5)要求用户从命令行或表单加载密码文件

6)通过networking提供密码

7)许多select(例如,画一个秘密,指纹,知识产权,Bla bla bla)

第一种select:我们可以通过使用混淆来使攻击者变得更加复杂,但这不是一个好的对策。 一个好的编码器可以很容易地理解它如何工作,如果他/她可以访问该文件。 我们甚至可以导出每个用户的二进制文件(或只是模糊处理部分或关键部分),因此攻击者必须能够访问这个用户特定的文件,而不是另一个发行版。 再次,我们应该find一种方法来更改密码,例如通过重新编译或使用reflection来实时更改类的行为。

第二种select:我们可以将encryption格式的密码存储在.properties文件中,所以它不能直接从攻击者看到(就像jasypt一样)。 如果我们需要一个密码pipe理器,我们还需要一个主密码,这个密码也应该存储在.class文件,密钥库,内核,另一个文件甚至是内存中 – 都有其优点和缺点。
但是,现在用户只需编辑.properties文件来更改密码。

第三个选项:从命令行运行时input密码,例如java -jar /myprogram.jar -p sdflhjkiweHIUHIU8976hyd

这不需要密码被存储,并将保持在内存中。 但是, history命令和操作系统日志,可能是你最大的敌人。 要实时更改密码,您将需要实现一些方法(例如,监听控制台input,RMI,套接字,REST bla bla bla),但密码将始终保留在内存中。

甚至可以在需要的时候临时解密 – >然后删除解密的内容,但始终将encryption的密码保存在内存中。 不幸的是,上述方法不会增加未经授权的内存访问的安全性,因为实现该目的的人可能有权访问algorithm,盐和任何其他正在使用的秘密。

第四个选项:从自定义表单提供密码,而不是命令行。 这将规避logging曝光的问题。

第五选项:提供一个文件作为先前存储在另一个媒体上的密码 – >然后硬删除文件。 这将再次规避logging曝光的问题,再加上不需要打字就可以肩上冲浪被盗。 当需要更改时,请提供另一个文件,然后再次删除。

第6个选项:为了避免肩上冲浪,可以实现RMI方法调用,以便从另一个设备(例如通过移动电话)提供密码(通过encryption的信道)。 但是,您现在需要保护您的networking通道并访问其他设备。

我会select上述方法的组合,以实现最大的安全性,所以人们将不得不访问.class文件,属性文件,日志,networking频道,肩上冲浪,中间人,其他文件。 这可以通过使用所有的子密码之间的XOR操作来实现,以产生实际的密码。

我们无法保护未经授权的内存访问,但这只能通过使用一些访问受限的硬件(例如智能卡,HSM,SGX)来实现,一切都计算在内,没有任何人,甚至合法的所有者能够访问解密密钥或algorithm。 再一次,也可以窃取这个硬件,有报道说可能帮助攻击者进行关键提取的边信道攻击 ,在某些情况下,你需要信任另一方(例如你信任英特尔的SGX)。 当然,安全飞地克隆(解体)将是可能的,情况可能会恶化,但我想这需要几年时间才能实用。

另外,可以考虑一个密钥共享解决scheme,其中全部密钥在不同的服务器之间被分开。 然而,重build后,全钥匙可以被盗。 减轻上述问题的唯一方法是通过安全的多方计算 。

我们应该永远记住,不pipeinput法如何,我们都需要确保我们不会受到networking嗅探(MITM攻击)和/或密钥logging器的攻击。

其实这是在configuration文件中encryption密码的副本? 。

到目前为止我发现的最好的解决scheme是在这个答案: https ://stackoverflow.com/a/1133815/1549977

优点:密码保存为一个字符数组,而不是一个string。 这还不好,但比其他任何事情都好。