网址会话 |身份验证质询响应

【问题标题】：URLSession | Authentication Challenge Response | NTLM网址会话 |身份验证质询响应 | NTLM
【发布时间】：2017-10-12 06:59:48
【问题描述】：

我知道How to Respond to an Authentication Challenge就像我们有NTLM Authentication一样，因为有3个选项。

但是只是想知道这里的想法，当我们使用第一个选项Provide authentication credentials时，我们传递用户名和密码URLCredential是否有泄漏凭据的可能性，传递凭据是否安全，什么是发生在屏幕后面？ Apple 网络 API 如何将凭据发送到服务器？

是的，我们可以设置服务器域、故障计数等策略，但从安全的角度来看，它安全吗？来自中间人攻击 (MIMA) 或其他什么？

【问题讨论】：

【解决方案1】：

也许我发布问题的方式尚不清楚，但我从应用程序凭据安全的角度看更多 NTLM Authentication 并且经过大量谷歌后，我发现 NTLM 是如何工作的，这很有趣该客户端不与服务器共享密码。步骤如下。

因此，有趣的部分在于 Network API 不与服务器共享密码，这意味着它非常安全。

希望对其他人有所帮助，For More。

【讨论】：

所以基本上，它是带有共享密钥的摘要认证，只有服务器提供的随机数。上述方案的最大缺点是没有安全的方法来更新密码，除非你有一个加密通道（例如 TLS），因为它使用共享的秘密（密码）而不是你可以安全发送到的证书清空服务器。
哦，它也比摘要式身份验证弱，因为只有 16 字节的 nonce 被哈希用于身份验证而不是整个请求，这意味着它不提供防止在传输过程中修改提交数据的保护。出于这个原因，我不会通过未加密的传输信任此身份验证方案。
@dgatwood 很高兴收到您的来信，您能否编辑一下这些内容，并附上您答案的链接，这对社区非常有帮助。我也想在这里了解更多。
我的错。 Digest auth 也只是加密一个随机数。我正在考虑一个完全不同的身份验证方案。 :-)

【解决方案2】：

挑战有多种类型，您的问题的答案取决于您所谈论的挑战类型。每个挑战都有一个保护空间，它基本上说明了您要应对的挑战类型。

回答您关于最常见保护空间的问题：

基于密码的基本身份验证 (NSURLAuthenticationMethodHTTPBasic)：您传递的凭据以明文形式发送到服务器 (HTTP) 或由会话密钥 (HTTPS) 加密。
摘要式身份验证 (NSURLAuthenticationMethodHTTPDigest)：您传递的凭据使用服务器提供的随机数进行加密哈希处理，并且只有生成的哈希令牌通过网络发送。
NTLM 身份验证 (NSURLAuthenticationMethodNTLM)：您传递的凭据使用服务器发送的随机数进行加密哈希处理，并且只有生成的哈希令牌通过网络发送。
客户端证书认证（NSURLAuthenticationMethodClientCertificate）：证书发送到服务器，但不发送私钥数据。客户端使用私钥对之前的 TLS 握手数据进行签名，作为让服务器验证客户端确实拥有与该证书关联的私钥的一种方式。
服务器证书验证 (NSURLAuthenticationMethodServerTrust)：如果您传递从服务器获得的证书，您必须首先验证它，否则您实际上会降低安全级别HTTP（即任何服务器都可以发送任何证书，并且在与服务器通信时您会说要信任该证书）。

上面的列表涵盖了最常见的保护空间。 Kerberos 是它自己的动物，我完全不知道它是如何工作的。还有“表单”保护空间，它只是自定义身份验证的占位符，您可以在应用代码的各个部分使用它，但实际上并没有以任何有意义的方式支持。

值得注意的是，如果攻击者可以更改传输中的数据，Basic、Digest 和 NTLM 身份验证无法防止中间人攻击，因为提供的身份验证令牌不依赖于请求的其余部分以任何方式。因此，这些确实只适合通过加密通道 (HTTPS) 使用。

【讨论】：

+1 感谢您的回复。我正在考虑我们在收到挑战时与服务器共享的凭据，它是否安全。可能我发的方式不太清楚。
我在此处添加了有关 NTLM 的信息。我还更正了 Digest auth 的解释。我将它与我想出的加密方案混淆了，实际上，它使用您的密钥对整个消息进行哈希处理，因此除了创建帐户/更改密码时，它在很大程度上不受 MITM 的影响。我的错。 :-) Digest auth 基本上与 NTLM 非常相似。