URLSession |身份驗證質詢響應| NTLM

Question

我知道How to Respond to an Authentication Challenge就像我們有NTLM Authentication那樣有3個選項。

• 提供認證憑證。
• 嘗試繼續沒有憑據。
• 取消認證請求。

但只是想知道這裏的想法，當我們的第一個選項Provide authentication credentials我們通過用戶名和密碼URLCredential去是有憑據的任何泄漏的可能性，是安全的傳遞憑據，發生了什麼在屏幕後面？ Apple網絡API如何將憑據發送到服務器？

是的，我們可以設置像服務器域，失敗計數等政策，但從安全的角度來看它是安全的嗎？從中間人攻擊（MIMA）或其他任何東西？

Answer 1

有多種類型的挑戰，您的問題的答案取決於您所說的挑戰類型。每個挑戰都有一個保護空間，它基本上告訴您正在響應哪種類型的挑戰。

要回答你的問題最常見的保護空間：

• 基本基於密碼的驗證（NSURLAuthenticationMethodHTTPBasic）：你通過憑證以明文發送到服務器（HTTP）或會話密鑰加密（HTTPS）。
• 摘要式身份驗證（NSURLAuthenticationMethodHTTPDigest）：您傳遞的憑據是使用服務器提供的隨機數加密散列的，並且只有得到的散列令牌通過網絡發送。
• NTLM身份驗證（NSURLAuthenticationMethodNTLM）：您傳遞的憑據使用服務器發送的隨機數對密鑰進行散列處理，只有得到的散列令牌通過網絡發送。
• 客戶端證書身份驗證（NSURLAuthenticationMethodClientCertificate）：證書發送到服務器，但不是私鑰數據。客戶端使用私鑰簽署之前的TLS握手數據，作爲讓服務器驗證客戶端確實擁有與該證書關聯的私鑰的一種手段。
• 服務器證書驗證（NSURLAuthenticationMethodServerTrust）：如果你通過從服務器獲取證書，則必須先驗證它，否則你有效地降低安全級別到HTTP（即任何服務器都可以發送任何證書，並且在與服務器交談時你會說相信該證書）。

上面的列表涵蓋了最常見的保護空間。 Kerberos是它自己的動物，對於它的工作原理我什麼也不知道。還有「表單」保護空間，它只是一個自定義驗證的佔位符，您可以在應用代碼的各個部分使用該空間，但實際上並未以任何有意義的方式支持該空間。

值得注意的是，如果攻擊者可以在傳輸過程中更改數據，Basic，Digest和NTLM身份驗證不提供針對中間人攻擊的保護，因爲所提供的身份驗證令牌並不依賴於其他身份驗證令牌以任何方式請求。因此，這些僅適用於加密通道（HTTPS）。

Answer 2

也許我發佈我的問題的方式並不清楚，但我從NTLM Authentication的應用程序憑據安全角度來看更多，並且經過大量Google之後，我發現NTLM如何工作，看到這一點非常有趣客戶端不會與服務器共享密碼。這裏是以下步驟。

1. 客戶端發出的請求到服務器。
2. 服務器需要驗證用戶，因爲沒有標識，因此服務器生成16字節的隨機數，稱爲挑戰並將其發送給客戶端。
3. 客戶端使用用戶的密碼對此挑戰進行哈希處理，並將其返回給被稱爲響應的服務器，它還包括用戶名作爲純文本和挑戰發送到客戶端。
4. 服務器將所有內容發送給域控制器，並使用用戶名從安全帳戶管理器數據庫檢索用戶密碼的哈希值，並對挑戰進行哈希處理。
5. 如果域控制器相同，則將響應共享回服務器，否則認證成功，否則失敗。

所以有趣的部分是在這裏，網絡API不與服務器共享密碼，這意味着它非常安全。

我希望它能幫助別人，For More。