我觉得我完全忽略了Wildfly中新的JCEKS密钥库格式.也许你可以让我直截了当.

我们配置Wildfly的方式(以及大部分互联网指示我们,for example)：

>我们将标准密钥库条目放在标准Java密钥库(“keystore.jks”)文件中,并带有密码(“jks_pw”)
>然后,我们使用密码,salt和round-count(“jceks_s_n”)创建一个JCEKS密钥库(“keystore.jceks”).
>然后我们将“pks_pw”放入“keystore.jceks”
>然后我们将JCEKS密码/ etc(“jceks_s_n”)作为纯文本添加到我们的jboss配置(standalone.xml)中,定义一个条目
>然后,我们将保管库存储的JKS密码的引用添加到我们的jboss https连接器(standalone.xml),作为“password =”${VAULT :: jks :: jks :: 1}“.

他们所做的一切完成了什么？

如果我们只使用嵌入在standalone.xml中的JKS文件和密码,系统很容易：

>攻击者获取standalone.xml和JKS文件的副本,在这种情况下,所有机密都是已知的.
>攻击者获取JKS文件的副本,在这种情况下,攻击者可以使用暴力攻击或查找表攻击.

如果我们按照描述的方式使用JCEKS容器,系统很容易：

>(相同)攻击者获取standalone.xml的副本,即JKS / JCEKS文件,在这种情况下,所有机密都是已知的.
>(SAME)攻击者获取JKS文件的副本,在这种情况下,攻击者可以使用暴力破解或查找表攻击.

如果我们将实际的证书放在JCEKS文件中,这将是有意义的,在这种情况下,暴力和查找表攻击在第二种攻击情况下会更难,但到目前为止我还没有找到使用方法直接使用https连接器的JCEKS格式的密钥库.

真的,我对此过分关注的唯一原因是我们显然有使用“保险库”的安全要求,但这似乎毫无意义.

更新：值得注意的是,通过使用保险库,您在jboss配置文件中使用了“屏蔽”密码到保险库,但我无法弄清楚这意味着什么.显然你的蒙面密码盐轮可以解锁JCEKS密钥库(source),所以我不确定完全屏蔽完成的是什么.它似乎是第三级重定向.我必须遗漏一些东西……

最佳答案 JBoss声称“保险库”背后的安全机制是默默无闻的安全措施(
https://developer.jboss.org/wiki/JBossAS7SecuringPasswords)

How secure is this?

• The default implementation of the vault utlizes a Java KeyStore. Its configuration uses Password Based Encryption, which is security by obscurity. This is not 100% security. It only gets away from the problem of clear text passwords in configuration files. There is always a weak link. (As mentallurg suggests in the comments, the keystore password is the weakest link).
• Ideally, 3rd party ISV robust implementations of Vaults should provide the necessary security.

Vault使用未知密码,算法对密钥库密码执行对称加密.如果没有HSM,您将始终面临“存储例如数据源密码”的问题.因此,通常您使用Access-Control-List定义属性文件并在其中存储编码密码.

保险库只会增加获取安全密码的工作量,使攻击者无法读取内存中的pw或对Vault加密算法密钥进行反向工程.