6

我觉得我完全错过了 Wildfly 中新的 JCEKS 密钥库格式的意义。也许你可以让我直截了当。

我们配置 Wildfly 的方式（例如，大部分互联网都指示我们这样做）：

  • 我们将标准密钥库条目放在标准 Java 密钥库（“keystore.jks”）文件中，并带有密码（“jks_pw”）
  • 然后，我们创建一个带有密码、salt 和循环计数（“jceks_s_n”）的 JCEKS 密钥库（“keystore.jceks”）。
  • 然后我们将“pks_pw”放入“keystore.jceks”
  • 然后我们将 JCEKS 密码/etc ("jceks_s_n") 作为纯文本添加到我们的 jboss 配置 (standalone.xml) 中，定义一个条目
  • 然后，我们向我们的 jboss https 连接器 (standalone.xml) 添加对保管库存储的 JKS 密码的引用，如“password="${VAULT::jks::jks::1}"。

这一切到底是为了什么？？？

如果我们只使用 JKS 文件和嵌入在 Standalone.xml 中的密码，系统很容易受到以下影响：

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

如果我们以所述方式使用 JCEKS 容器，系统容易受到以下影响：

  • （相同）攻击者获取了standalone.xml 的副本，即 JKS/JCEKS 文件，在这种情况下，所有秘密都是已知的。
  • （相同）攻击者获取 JKS 文件的副本，在这种情况下，攻击者可以使用暴力破解或查找表攻击。

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

真的，我太在意这个的唯一原因是我们显然有使用“保险库”的安全要求，但这似乎毫无意义。

更新：值得注意的是，通过使用 vault，您在 jboss 配置文件中使用 vault 的“屏蔽”密码，但我不知道这意味着什么。显然，您的掩码密码 + 盐 + 回合可以解锁 JCEKS 密钥库（source），所以我不确定掩码究竟能完成什么。这似乎是第三级重定向。我一定是错过了什么...

4

2 回答 2

1

重要的是要知道“保险库”背后的安全机制是隐匿安全，这意味着您只是在掩盖您的感知数据。这意味着如果攻击者可以访问您的standalone.xml 和密钥库，他可以轻松读取您的所有数据。保险库“增加了努力”-> 攻击者无法直接看到它们，但需要付出一些（一点点）努力。

于 2018-05-23T08:28:11.760 回答
1

JBoss 指出“保险库”背后的安全机制是默默无闻的安全机制（https://developer.jboss.org/wiki/JBossAS7SecuringPasswords）

这有多安全？

  • 保险库的默认实现使用 Java KeyStore。它的配置使用基于密码的加密，这是通过默默无闻的安全性。这不是 100% 的安全性。它只解决了配置文件中明文密码的问题。总是有一个薄弱环节。（正如mentallurg 在评论中所建议的，密钥库密码是最薄弱的环节）。
  • 理想情况下，第 3 方 ISV 健壮的 Vault 实施应提供必要的安全性。

Vault 使用未知密码和算法对密钥库密码执行对称加密。如果没有 HSM，您将始终面临“将数据源密码等存储在何处”的问题。所以通常你会定义一个带有访问控制列表的属性文件并将编码的密码存储在那里。

保险库只是增加了获取安全密码的工作量，让攻击者要么读取内存中的密码，要么对保险库加密算法+密钥进行逆向工程。

于 2017-05-03T16:32:14.717 回答