服务器是否决定要遵循的身份验证方法？

Question

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

像 NTLM 和 Kerberos 浏览器这样的身份验证方法是特定的吗？

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

谢谢你:)

Answer 1

正如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 中描述的基本和摘要机制以及RFC 4559 中描述的使用“SPNEGO”（协商机制）的 NTLM 或 Kerberos。

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

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

2. Digest 是一种质询/响应机制，它依赖于散列算法，在这一点上，散列算法不被认为具有加密强度。

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

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

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