URLSession /身份验证挑战响应

Question

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

• 提供身份验证凭证。
• 试图在没有凭据的情况下继续。
• 取消身份验证请求。

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

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

Answer 1

也许我发布问题的方式还不清楚，但我更多的是从NTLM认证的应用程序证书安全的角度看问题。在谷歌大量搜索之后，我发现NTLM是如何工作的，而且很有趣的是，客户端不与服务器共享密码。以下是以下步骤。

​

​

1. 客户端向服务器发出请求。
2. 服务器需要验证用户，因为没有标识，因此服务器生成16字节随机数作为挑战，并将其发送到客户端。
3. 客户端使用用户的密码散列此挑战，并将其返回到称为响应的服务器，它还包括用户名作为纯文本并发送给客户端。
4. 服务器将所有内容发送给域控制器，并使用用户名从安全帐户管理器数据库检索用户密码的哈希，并对挑战进行散列。
5. 域控制器将响应共享给服务器，如果它们是相同的，那么身份验证就会成功，否则就会失败。

有趣的是，Network不与服务器共享密码，这意味着它非常安全。

我希望它能帮助到其他人，想要更多。

Answer 2

有多种类型的挑战，你的问题的答案取决于你说的是什么类型的挑战。每个挑战都有一个保护空间，它基本上告诉您响应的是哪种类型的挑战。

要回答最常见的保护空间的问题：

• 基本基于密码的身份验证(NSURLAuthenticationMethodHTTPBasic)：您传递的凭据以明文形式发送到服务器(HTTP)或由会话密钥(HTTPS)加密。
• 摘要身份验证(NSURLAuthenticationMethodHTTPDigest)：您所传递的凭据是用服务器提供的nonce加密散列的，并且只有得到的散列令牌才会通过网络发送。
• NTLM身份验证(NSURLAuthenticationMethodNTLM)：您传递的凭据是加密的散列，服务器发送的是nonce，只有得到的散列令牌才会通过网络发送。
• 客户端证书身份验证(NSURLAuthenticationMethodClientCertificate)：证书发送到服务器，但不发送私钥数据。客户端使用私钥对先前的TLS握手数据进行签名，以使服务器验证客户机确实拥有与该证书相关联的私钥。
• server 证书验证 (NSURLAuthenticationMethodServerTrust)：如果您通过了从服务器获得的证书，则必须首先验证该证书，否则您必须有效地将安全性级别降低到HTTP的安全级别(也就是说，任何服务器都可以发送任何证书，并且在与服务器交谈时会说要信任该证书)。

上面的清单涵盖了最常见的保护空间。Kerberos是它自己的动物，我对它的工作原理一无所知。还有“表单”保护空间，它只是一个用于自定义身份验证的占位符，您可以在应用程序代码的各个部分中使用它，但实际上并不支持任何有意义的方式。

值得注意的是，如果攻击者可以在传输过程中更改数据，则Basic、Digest和NTLM身份验证不提供防范中间人攻击的保护，因为所提供的身份验证令牌在任何方面都不依赖于请求的其余部分。因此，它们实际上只适合在加密通道(HTTPS)上使用。