HTTP系列(第4部分):認證機制

在上一部分中,我們討論了網站用於識別訪問用戶的不同方式。

但身份識別本身只是一種說法。當你認出自己時,你 聲稱自己就是某個人。但沒有證據證明這一點。

另一方面,身份驗證顯示您聲稱自己是您所宣稱的,例如顯示您的個人ID或輸入您的密碼。

通常,網站需要該證明才能為您提供敏感資源。

HTTP有自己的身份驗證機制,允許服務器發出挑戰並獲得所需的證據。在本文中,您將瞭解它們是什麼以及它們如何工作。我們還將介紹每個人的優點和缺點,並找出他們是否真的足夠自己使用(劇透:他們不是)。

這是HTTP系列的第四部分。

在本文中,您將瞭解更多信息:

  • HTTP身份驗證的工作原理
  • 基本認證
  • 摘要式身份驗證

在深入探討具體的HTTP身份驗證機制之前,讓我們探討一下HTTP身份驗證的內容。

HTTP身份驗證如何工作?

身份驗證是一種向Web服務器標識自己的方法。您需要證明您有權訪問所請求的資源。通常,這是通過使用服務器驗證的用戶名和密碼(密鑰和密碼)的組合來完成的,然後決定是否可以訪問資源。

HTTP提供兩種身份驗證協議:

  • 基本認證
  • 摘要式身份驗證

在詳細瞭解每一個之前,讓我們先了解一些基本概念。

挑戰/響應認證框架

這是什麼意思?

這意味著當有人發送請求而不是立即響應請求時,服務器會發送

身份驗證質詢。它通過輸入秘密信息(用戶名和密碼)來挑戰用戶提供身份證明。

之後,使用提供的憑據重複請求,如果它們正確,則用戶獲得預期的響應。如果憑據錯誤,服務器可以重新發出質詢或僅發送錯誤消息。

身份驗證相關的請求/響應頭

服務器通過使用WWW-Authenticate響應頭來發出挑戰它包含有關身份驗證協議和安全領域的信息。

客戶端輸入憑據後,將再次發送請求。這次使用包含身份驗證算法和用戶名/密碼組合的Authorization標頭

如果憑據正確,則服務器會在可選的Authentication-Info響應標頭中返回響應和其他信息。

安全領域

安全領域提供了

將不同訪問權限關聯到服務器上的不同資源組的方法。這些被稱為保護空間。

這有效意味著,根據您要訪問的資源,您可能需要輸入不同的憑據。

服務器可以有多個領域。例如,一個是網站統計信息,只有網站管理員才能訪問。另一個是其他用戶可以訪問和上傳圖像的網站圖像。

/admin/statistics/financials.txt - > Realm =“管理員統計”

/images/img1.jpg - > Realm =“Images”

當您嘗試訪問financials.txt時,服務器將挑戰您,響應將如下所示:

HTTP系列(第4部分):認證機制

簡單的HTTP身份驗證示例

現在讓我們通過查看最簡單的HTTP身份驗證示例(基本身份驗證,如下所述)來連接點:

HTTP系列(第4部分):認證機制

現在讓我們深入研究並研究基本身份驗證。

基本認證

最流行和支持的身份驗證協議。它自HTTP / 1.0以來一直存在,並且每個主要客戶端都實現它。

上面的示例描述瞭如何使用基本身份驗證進行身份驗證。它的實現和使用相當簡單,但它有一些安全漏洞。

在討論安全問題之前,讓我們看看基本身份驗證如何處理用戶名和密碼。

基本身份驗證將用戶名和密碼打包到一個字符串中,並使用冒號(:)分隔它們。之後,它使用Base64編碼對它們進行編碼。儘管它看起來很像,但亂碼的字符序列並不安全,您可以輕鬆解碼它

Base64編碼的目的不是加密,而是使用戶名和密碼HTTP兼容。主要原因是您不能在HTTP標頭中使用國際字符。

HTTP系列(第4部分):認證機制

這個例子中的“Zm9vOmJhcg ==”只不過是Base64編碼的“foo:bar”字符串。

因此,任何收聽請求的人都可以輕鬆解碼並使用憑據。

更糟糕的是,編碼用戶名和密碼無濟於事。惡意第三方仍然可以發送加擾序列以達到相同的效果

沒有針對代理或任何其他類型的攻擊的保護,這些攻擊會更改請求正文並使請求頭保持不變。

因此,正如您所看到的,基本身份驗證不是完美的身份驗證機制。

儘管如此,您仍然可以使用它來防止意外訪問受保護的資源,並提供一定程度的個性化。

為了使其更安全和可用,可以使用HTTPS over SSL實現基本身份驗證,我們將在本系列的第5部分中討論。

有人會認為它只有你的運輸機制一樣安全。

摘要式身份驗證

摘要式身份驗證是一種比簡單但不安全的基本身份驗證更安全可靠的替代方法。

那麼它是怎樣工作的?

摘要式身份驗證使用MD5加密散列 nonce的使用相結合 這樣它隱藏了密碼信息以防止各種惡意攻擊。

這可能聽起來有點複雜,但當你看到它如何在一個簡單的例子上工作時它會變得更清晰。

HTTP系列(第4部分):認證機制

HTTP系列(第4部分):認證機制

詳細說明

我們來定義這些:

  • nonceopaque - 服務器定義的客戶端在收到它們時返回的字符串
  • qop(保護質量)
    - 一個或多個預定義值(“auth”|“auth-int”|令牌)。這些值會影響摘要的計算。
  • 如果設置了qop,則必須生成cnonce - client nonce。它用於避免選擇的明文攻擊 並提供消息完整性保護。
  • 如果設置了qop,則必須發送nc - nonce計數。該指令允許服務器通過維護自己的此計數副本來檢測請求重放 - 如果相同的nc值出現兩次,則請求是重放。

響應屬性按以下方式計算:

HTTP系列(第4部分):認證機制

如果您有興趣學習如何根據qop計算響應,可以在RFC 2617中找到它。

HTTP系列(第4部分):認證機制

服務器自己計算哈希並比較兩者。如果它們匹配,它將為客戶端提供所請求的數據。

簡短的摘要

如您所見,摘要式身份驗證的理解和實現更加複雜。

它比基本身份驗證更安全,但仍然容易受到中間人攻擊。RFC 2617建議使用摘要式身份驗證而不是基本身份驗證,因為它可以彌補它的一些弱點。它也沒有掩蓋現代加密標準仍然很弱的摘要式身份驗證這一事實 它的實力在很大程度上取決於實施。

所以在摘要摘要認證中:

  • 不通過網絡發送純文本密碼
  • 防止重播攻擊
  • 防止消息篡改

一些弱點:

  • 對中間人攻擊的脆弱性
  • 許多安全選項不是必需的,因此如果沒有設置,則使摘要認證功能以不太安全的方式運行
  • 存儲密碼時,禁止使用強密碼哈希算法

由於這些事實,摘要認證仍未獲得重大牽引力。基本身份驗證更簡單,並且與SSL相結合仍然比摘要身份驗證更安全。

結論

這是HTTP系列的這一部分。

我們已經完成了默認情況下HTTP提供的不同身份驗證機制,並討論了它們的優缺點。

希望這些概念不僅僅是屏幕上的字母了,下次當你聽到它們時,你會準確地知道它們是什麼以及何時應用它們。

您還意識到這些身份驗證機制尚未解決安全風險。這就是為什麼存在HTTPS和SSL / TLS等概念的原因。我們將在本系列的下一部分中詳細討論安全風險以及如何解決這些問題。


分享到:


相關文章: