JDK8 在其JavaKeyStore 类中使用SHA 算法。
从源代码中，您可以看到在engineLoad 期间 - 如果提供密码 - 它会根据提供的密码生成一个 SHA MessageDigest。如果我正确获取代码，则密钥库的条目会提前使用密码进行签名。 SHA-Password-MessageDigest 用于通过将存储的哈希值与计算的哈希值进行比较来检查完整性 - 对于每个条目。
由于已知 SHA 在某些情况下不安全，因此运行时扫描程序会生成安全性调查结果。使用 Java 的 KeyStore（例如 Apache Kafka）的软件可能会受到影响。
我想知道这个安全问题在实践中有多严重。可能的攻击媒介有哪些？
我想听听别人的评价。
【问题讨论】：
标签： java security java-8 cryptography
不，这是绝对不安全的。每当使用密码加载 Java KeyStore (.jks) 时都会使用它。然后它根据读取的数据计算这个可怜的人的 MAC，然后 将其与存储的密码哈希值进行比较。
由于它只计算内容、密码和静态魔法字符串"Mighty Aphrodite" 的 SHA-1，因此非常容易执行，例如字典或彩虹表攻击。您甚至可以通过简单地首先计算数据并存储中间哈希值来显着加快速度。所以它不是不安全的，因为它大量使用损坏的 SHA-1 哈希 - 虽然这也是一个问题 - 但因为它可以很容易地恢复使用过的密码。使用具有高迭代次数的 PBKDF2 并在密码安全性不足的情况下发出警告可以避免此问题。
当前的 SHA-1 攻击仍然需要预先计算，我们可以假设密钥库内容通常不是由对手预先计算的。尽管如此，SHA-1 还是被破坏了 w.r.t。抗碰撞性，因此文件的完整性不能完全保证。
我看不出长度扩展攻击会使情况变得更糟，因为条目是在使用密码之前读取的，所以幸运的是它应该没问题。然而，更换密码根本不是问题，这可能会被用于社交攻击（您是否使用了错误的密码“hi”来保护它？也许您应该更换该密码？）。
请注意，从 Java 9 开始，您确实应该使用比 JKS 更好的密钥库（例如 PKCS#12 密钥库）。
【讨论】：
JavaDoc 明确表示这样做的意图是
防止篡改密钥库
这一切都取决于您的安全目标。
由于众所周知 SHA 不安全
SHA 并非“不安全”。这是一个过于简单化的评估。对于散列密码来说，它太快了。对于许多其他用例来说，它是完全“安全”的。
显然，密钥库不是密码，因此安全目标是不同的。密钥库是本地文件。通常，如果恶意用户可以物理访问您的计算机，那么这场战斗就已经失败了。
在这种情况下，哈希比其他任何东西更多地用于完整性和真实性。在这种情况下，SHA 是一个不错的选择。
【讨论】：
It is perfectly "safe" for many other use-cases.? 如果我们假设 SHA 表示 SHA-1，那么它并不完全安全In 2020, SHA-1 practically broken in chosen-prefix collision (CP-collision). Can double SHA-1 hashing prevent CP-collision?/ 前映像电阻和次映像电阻都可以，但是，它不能防止碰撞。 SHA-1 在 2011 年左右从推荐中删除，具有讽刺意味的是，这等于 1997 年、2011 年的版权日期