【讀】這一次,讓咱們再深刻一點 - HTTP的摘要認證

這是網絡系列的第十篇文章,接下來會有更多精彩內容.敬請期待! 讓咱們一塊兒乘風破浪!

前言

上篇中咱們瞭解到了HTTP認證框架中的基本認證. 它是基於質詢/響應模型的.這篇中, 咱們粗略的瞭解下另外一種認證協議: 摘要認證. 固然摘要認證也不是最安全的認證方式, 而且至今沒有普遍運用. 可是其相關概念仍是值得學習的.下面進入正文!

摘要認證的改進

摘要認證是HTTP支持的另外一種認證協議, 其試圖修復基本認證的缺陷. 改進以下:

• 不會以明文的方式發送密碼.
• 能夠防止惡意用戶捕獲和重放認證的握手過程.
• 能夠有選擇的防止對報文內容的篡改.
• 防範其餘幾種常見的攻擊方式.

以摘要保護密碼

摘要認證遵循的諫言是"毫不經過網絡發送密碼". 客戶端不會直接發送密碼, 而是發送密碼的"指紋"或"摘要"(能夠理解爲密碼通過加密過的東西, 它是不可逆的).對比基本認證過程, 一塊兒來看下摘要認證的過程:

由上面的過程, 能夠看到, 客戶端和服務器在知道用戶名的狀況下經過摘要進行認證, 沒有傳輸密碼. 第三方也就沒法獲取用戶密碼. 從而保護了密碼的安全.

單向摘要

經常使用來生成摘要的方法是使用MD5, 這是一個單向的, 不可逆的過程. 它會對不肯定的輸入, 產生固定128位的輸出, 表示輸入信息的摘要.一般, 128位的信息會以32位的十六進制表示.

用隨機數防止重放攻擊

你可能會想到, 第三方能夠獲取摘要, 以經過服務器的認證. 因此, 這裏加入了"隨機數"來防止這種狀況的出現. 服務器在質詢時向客戶端發送隨機數, 客戶端在生成摘要時須要使用到它. 固然, 隨機數是變化的, 這樣能夠有效的防止重放攻擊.

摘要認證的握手機制

摘要認證是基本認證的升級版本, 所用的首部和基本認證大體相同, 只是增長了Authorization-Info首部, 服務器在認證經過後向客戶端發送認證相關信息.

• 服務器在收到須要認證的請求後, 在(1)中生成隨機數, 經過WWW-Authenticate首部發送給客戶端(2).
• 在(3)中, 客戶端選擇摘要算法, 經過密碼和其餘信息計算出摘要. 在(4)中經過Authorization首部發送給服務器. 若客戶端須要服務器進行認證, 能夠發送客戶端隨機數.
• (5)中, 服務器接收摘要, 計算本身的摘要, 並驗證. 若客戶端對服務器進行了摘要認證, 服務器會在(6)中發送計算的摘要, 客戶端在接收到數據後就能夠進行認證了.

摘要的計算

下面一塊兒來了解下摘要時如何計算的

摘要算法的輸入數據

• 單向散列函數H(d), 和摘要KD(s,d)組成的一對函數, 其中s表示密碼, d表示數據.
• 一個保護了安全信息的數據塊, 包括密碼, 稱爲A1
• 一個保護了請求報文中非保密屬性的數據塊, 稱爲A2

使用H和KD處理A1和A2, 產生摘要.

算法H(d)和KD(s, d)

摘要認證支持多種算法, 可是文檔RFC 2617建議使用MD5和MD5-sess, 若沒有指定算法, 默認採用MD5.具體以下:

H(d) = MD5(d)
KD(s, d) = H(concatenate(s:d))
複製代碼

與安全性相關的數據A1

A1的生成和算法有關, 根據RFC 2617, 有以下規則:

• MD5算法A1的構成:

  A1 = <user>:<realm>:<password>
  複製代碼

• MD5-sess算法A1的構成:

  A1 = MD5(<user>:<realm>:<password>):<nonce><cnone>
  其中, nonce表示當前隨機數, cnone表示客戶端隨機數
  複製代碼

與報文有關的相關數據A2

A2表示了和報文相關的信息, 好比URL, 請求方法, 報文主體等. A2有助於防止方法, 資源或報文被篡改.

RFC 2617說明, 根據選擇的保護質量(qop), A2有兩種策略:

• 當qop="auth"時, 只包含請求方法和URL.
• 當qop="auth-int"時, 不只含請求方法和URL, 還添加了報文主體部分.

qop	A2
auth	<\request-method> : <\uri>
auth-int	<\request-method> : <\uri> : H(request-body)

摘要算法總述

在瞭解了計算摘要所必須的元素後, 接下來了解下這個摘要最終是怎麼計算的. 然而在計算最終結果時, 又出現了兩種狀況: 請求不包含qop(爲了兼容以前的規範), 請求包含qop.

qop	計算方式	說明
未定義	KD(H(A1), <\nonce>:H(A2))	不推薦
auth 或 auth-int	KD(H(A1), <\nonce>:<\nc>:<\cnonce>:<\qop>:H(A2))	推薦

其中nc也是客戶端發送的用於驗證的數據.

摘要認證會話

客戶端響應對對保護空間的WWW-Authenticate質詢時, 會啓動該保護空間的認證會話.在客戶端收到另外一條來至保護空間的任意一臺服務器的質詢以前,認證會話一直持續. 客戶端應該記住認證相關信息, 以便未來在此保護空間中構建請求的Authorization首部時使用.

在認證過時時, 客戶端也可使用相關信息來構建請求首部, 而沒必要讓用戶再次輸入帳戶和密碼.

預受權

在普通的認證過程當中, 每一個請求都會有質詢環節(參考下圖的a).

而若是客戶端在有過 請求質詢的過程後, 事先知道認證須要的下一個隨機數, 就能夠直接發送帶有 Authorization首部的請求, 這樣就能夠取消以後的 質詢環節了(參考上圖的b).

預受權對基本認證來講並不重要(參考這裏). 客戶端在對某一個站點認證後, 在通過用戶贊成能夠記住用戶名和密碼, 下次再對這些站點認證時, 就能夠直接發送用戶名和密碼了.

而對於摘要認證來講, 假如了隨機數來防止重放攻擊. 服務器的隨機數是任意的, 客戶端在收到質詢以前, 沒法生成正確的Authorization首部.

爲了進行預受權, 這裏有三種生成隨機數的方式, 客戶端知道隨機數後, 就能夠生成正確的Authorization首部.

• 服務器在Authentication-Info首部預先發送下一個隨機數.
• 服務器容許在一小段時間內使用相同隨機數.
• 服務器和客戶端使用同步的, 可預測的隨機數生成算法.

對稱認證

對稱認證是指服務器對客戶端發出質詢後, 客戶端也能夠對服務器進行認證. 這需客戶端發出客戶端隨機數, 服務器在計算摘要後, 經過Authorization-Info首部發送給客戶端.

經過上文的瞭解, 生成摘要須要A2(它是與報文有關的相關數據), 包含了請求方法. 而相應報文中是沒有請求方法的. 因此A2的肯定有不一樣之處, 以下:

qop	A2
auth	: <\uri>
auth-int	: <\uri> : H(response-body)

須要注意的幾個問題

多重質詢

服務器在不知道客戶端的具體能力時, 能夠對客戶端既發出基本認證質詢,又發出摘要認證質詢. 客戶端在在面臨多重質詢時, 必須以它支持的最強的機制來應答.

差錯處理

在摘要認證中, 客戶端在請求時若某一個指令或其值使用不當, 或者缺乏某個指令, 服務器就應該以400 Bad request響應.

若是請求的摘要不匹配, 就應該記錄一次登陸失敗, 一客戶端連續屢次失敗, 可能存在攻擊者在猜想密碼.

服務器必定要肯定URL指令的值和請求行中的值相同.服務器也應該以400 Bad request響應.

保護空間

經過域能夠將服務器的資源劃分爲不一樣的保護空間. 每個保護空間都有本身的認證機制. 保護空間決定了能夠自動應用證書的區域. 好比某條請求已經被受權, 再接下來的一段時間內, 該保護空間的其餘請求也可使用該證書.若沒有想過說明, 單個保護空間是不能擴展到其餘範圍的.

重寫URI

若請求通過了代理, 而代理對URI進行了重寫.這樣就會破壞摘要認證.由於摘要認證會對URI進行檢查.

結語

好了, 對於摘要認證就介紹到這裏. HTTP原生認證的一些安全風險並未詳細展開. 有興趣的同窗能夠繼續研究下.經過學習, 能夠發現HTTP的最初設想仍是多方面的, 只是沒有對應時代的需求啊.

注

• 部分圖片來源於網絡，若有侵權，請告知。
• 若有錯誤，還請指出。共勉！
• 您的喜歡是最大的讚揚。