全面披露：我曾担任过一段时间的 Kerberos 项目经理，目前是微软的一名开发人员。

你所描述的并不完全准确。最初指定的 Kerberos 确实依赖对称加密进行身份验证。但是，此规范有广泛使用的扩展，可以支持 PKI 身份验证并阻止客户端 *-roasting。例如，Windows 使用 PKINIT 扩展来进行智能卡身份验证和 Windows Hello。

此外，弱点不是秘密是对称的，而是秘密通常是用户生成的，这意味着很容易猜到，或者他们选择了弱密码套件。切换到基于非对称加密的协议只是将问题从“我如何生成密钥”转移到“我如何存储和保护密钥”。在实践中，由于不同的原因，两者都是同样困难的问题。

非对称密钥也不能解决类似金票的问题。如果您能够窃取 krbtgt 对称密钥，那么是什么阻止您窃取不对称密钥？不是很多。如果您能够保护非对称密钥，为什么您不能保护对称密钥？事实上，由于性能优势，今天许多系统使用对称密钥来保护这些类型的令牌，例如会话 cookie 或刷新令牌。使其不对称并不能直接改善事情（尽管应用程序架构可能另有规定）。

银票问题确实受益于转向非对称，因为服务永远不需要知道私钥，这降低了它泄露的可能性。

但是，这样做您放弃了相互身份验证的保证。对称算法的特性是，因为双方都知道秘密，所以相互认证（当多方知道时，系统就会失败）。使用非对称密钥无法保证收到票的一方实际上就是他们所说的那个人。您现在需要对双方进行显式身份验证，这可以通过添加另一个非对称密钥来完成，但现在您至少已经使此交换所需的密钥总数增加了一倍。你仍然被困在双方保护一个秘密。

切换到另一个协议的替代方案实际上也很难实现。有些系统根本不会移动，而会移动的系统将在很多年之后移动。这需要让许多标准机构、软件实施者和公司参与进来，并让他们相信所有这些都是最好的。这并不是说这是不可能的，甚至不是一个坏主意。只是这样做并取得成功所需的努力是巨大的。

或者，您可以对当今使用 Kerberos 的方式进行微调，并获得非常好的 (tm) 安全性。

• 抛弃密码（智能卡、Windows Hello、FIDO 等）
• 使用强生成的服务帐户密码（gMSA 等）
• 禁用弱密码（DES、RC4）
• 启用复合身份验证（装甲）