我觉得我完全错过了Wildfly中新的JCEKS密钥库格式的要点。也许你可以让我挺直。
我们配置Wildfly的方式（很多互联网指示我们for example）：
我们将标准密钥库条目与密码（“ jks_pw”）一起放入标准Java密钥库（“ keystore.jks”）文件中
然后，我们创建一个JCEKS密钥库（“ keystore.jceks”），并带有密码，盐和整数（“ jceks_s_n”）。
然后，将“ 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文件）的副本，在这种情况下，所有机密都是已知的。
（相同）攻击者获取JKS文件的副本，在这种情况下，攻击者可以使用蛮力攻击或查找表攻击。
如果我们将实际的证书放入JCEKS文件中，这将很有意义，在这种情况下，蛮力和查找表攻击在第二种攻击情况下会更困难，但到目前为止，我还没有找到使用方法直接使用https连接器的JCEKS格式的密钥库。
确实，我对此太在意的唯一原因是我们显然对使用“保险库”有安全要求，但这似乎毫无意义。
更新：值得注意的是，通过使用保管库，您在jboss配置文件中使用了“已屏蔽”密码登录保管库，但我不知道这是什么意思。显然，您的掩码密码+盐+回合可以解锁JCEKS密钥库（source），因此我不确定掩码到底能完成什么。好像只是重定向的第三层。我一定要错过一些东西...
最佳答案
JBoss指出，“保险库”背后的安全性机制是默默无闻的安全性（https://developer.jboss.org/wiki/JBossAS7SecuringPasswords）
这有多安全？
保管库的默认实现是使用Java KeyStore。它的配置使用基于密码的加密，这种加密从本质上是安全的。这不是100％的安全性。它仅解决了配置文件中明文密码的问题。总会有一个薄弱的环节。 （正如mentallurg在评论中建议的那样，密钥库密码是最弱的链接）。
理想情况下，保管库的第三方ISV稳健实现应提供必要的安全性。
保险柜使用未知密码，并且算法对密钥库密码执行对称加密。没有HSM，您将始终面临“例如数据源密码存储在何处”的问题。因此，通常情况下，您将使用访问控制列表定义属性文件，并将编码后的密码存储在那里。
保管库只会增加获取安全密码的工作量，而使攻击者只能读取内存中的pw或对保管库加密算法+密钥进行反向工程。