可以说，Kerberos 未在公共 Internet 上使用的原因与协议的安全性或 KDC 的公开无关，而是因为它是一种不适合大多数“公共”需求的身份验证模型互联网”应用程序。

引用 Wikipedia 的话，Kerberos “提供相互身份验证——用户和服务器都验证彼此的身份。 ”这意味着客户端机器需要在用户身份验证发生之前拥有必要的密钥来证明其身份。将这些密钥分发给“公共互联网”应用程序是不切实际的，原因有几个——考虑一下有多少 PC 访问您的银行网站，而这些网站的所有者是各种各样的人，他们定期安装 Windows 补丁程序的能力很紧张。企业 IT 不会出现并为他们配置 Kerberos。

Kerberos 需要紧密同步的时钟——在集中管理的企业或教育环境中做到这一点并不难，但当机器都由完全不同的人拥有和管理时则困难得多。

Kerberos 的优势之一是能够无缝地将初始身份验证用于多个应用程序访问。在公共 Internet 上，多个应用程序之间很少有任何关系——我的银行、我的邮件和我的 /。帐户没有电话可以信任彼此或同一组人。（这属于联合身份领域，并且在该领域有工作，但它不需要 Kerberos 带来的相同组合）。

简而言之，Kerberos 是一个重量级的解决方案，而公共 Internet 应用程序访问控制是一个轻量级的问题。

要直接回答您的实际问题，不，我不认为对暴力攻击或 KDC 漏洞的担忧会使 Kerberos 无法访问 Internet。该协议经过 20 多年的合理审查、攻击、修复和更新。仅客户端（机器）身份验证部分就提供了巨大的保护，可以抵御在大型开放网络（如 Internet）上预期的大量攻击。

在 Internet 上使用 Kerberos 本身通常是安全的。毕竟，它的设计目的是在世界上最具敌意的公共网络之一：麻省理工学院校园网络上保持安全。

Kerberos 白皮书“为什么 Kerberos 是可靠的安全解决方案？” 解决您提出的所有问题。部分引用：

从未公开或通过网络发送的密码对于攻击者来说更难窃取。因此，用户的 Kerberos 身份验证不需要向身份验证服务提供密码。相反，Kerberos 身份验证服务使用加密协议，用户可以通过该协议证明拥有密码，而无需实际透露密码。

在分布式环境中，在需要对请求进行身份验证的每个客户端和服务器上维护共享机密（例如密码）会非常尴尬。此外，在许多系统中分发共享机密会增加与系统数量成正比的潜在漏洞——“最弱链接”现象加剧了这个问题。Kerberos 通过维护一个仅分布在几个身份验证服务器上的集中式数据库来满足这一要求。虽然整体安全性严重依赖于保护这个中央数据库，但加固一些专用服务器以抵御攻击要比保护许多通用系统容易得多。对身份验证秘密的集中控制还可以更轻松地发布新凭证、撤销现有凭证、

Kerberos 开发人员假设任何人都可以窃听网络流量，可以声称自己是任何用户，并且可以设置能够伪装成任何合法服务的恶意服务器，包括 Kerberos 服务本身。加密用于防止窃听攻击，并引入会话密钥和时间戳以防止重放攻击。当用户（或主机/服务）向 Kerberos 身份验证服务进行身份验证时，身份验证服务反过来通过证明它知道先前建立的共享密钥来向用户（或主机/服务）进行身份验证。这些反措施的一个副产品是，Kerberos 提供了对中间人攻击的保护，这在当时被普遍认为是不可行的，并且在 Kerberos 最初部署后的十多年里。可悲的是，

如果您可以合理地将所有系统加入到 Kerberos 领域，例如它们都是您公司内的站点，那么使用它应该没问题。但是，它不一定会加密所有内容；例如，HTTP 仍然是未加密的。不过，某些服务（例如 NFS）可以使用 Kerberos 加密其数据流。根据您的应用程序和要传输的数据，您可能仍希望在站点之间使用 VPN。

但是，如果您的应用程序要向公众开放，那么 Kerberos 可能不是您想要的。