0

对于 Web 应用程序，服务器是否决定要遵循的身份验证方法还是客户端。

NTLM 和 Kerberos 浏览器等身份验证方法是否特定。

在 Intranet Web 应用程序中，与 NTLM 和 Kerberos 相比，BASIC 和 Diget 处于什么位置？

谢谢你 ：）

4

1 回答 1

0

正如RFC 2617中所讨论的，它需要双方的合作。

当访问资源需要凭据时，服务器将发送回一个401响应，其中包含一个或多个WWW-Authenticate标头，指示它支持的身份验证类型。如果有多个WWW-Authenticate标头，客户端“必须选择使用它理解的最强身份验证方案并根据该挑战请求凭据。”

所以回应可能是：

WWW-Authenticate: Basic realm="protected area"
WWW-Authenticate: Digest
        realm="protected area"
        qop="auth"
        nonce="ea9c8142787af00ec11bd0eac248cac930"
        opaque="cdc069ca3ffe57acff21c259deadbeef"
WWW-Authenticate: Negotiate

这表明服务器愿意接受RFC 2617中描述的 Basic 和 Digest 机制，以及使用RFC 4559中描述的“SPNEGO”（协商机制）的 NTLM 或 Kerberos 。

然后，客户端必须确定这些方案中哪一个是最强的并再次发送请求。这取决于所讨论的用户代理，但这些机制的评级为假定弱到强（因此最优选的是last）：

  1. Basic不提供安全性，明文密码可以轻松恢复。仅当对安全性的期望完全为零或该层已使用 TLS 加密时才应使用。

  2. 摘要是一种挑战/响应机制，它依赖于散列算法，在这一点上，这些算法在密码学上不被认为是强大的。

  3. NTLM是一系列挑战/响应机制，即使在其最强（NTLMv2）的情况下，它也依赖于加密强度不高的哈希算法。然而，NTLM 的一个优势是，Windows 计算机上的用户在登录期间对其密码进行哈希处理，这样他们就可以成为算法的输入，从而允许“单点登录”到网站，而无需重新输入密码。

  4. Kerberos使用受信任的密钥分发中心 (KDC) 提供安全身份验证，是 Intranet 的绝佳选择，但不太可能成为 Internet 上所有客户端的可行机制。

通过使用 TLS 保护会话以提供传输加密，可以减少任何这些协议的弱点的影响，并且绝对应该在任何不受信任的网络（即整个互联网）上执行。

于 2012-10-18T15:35:39.017 回答