HTTP認證之摘要認證——Digest(一)

導航

  • HTTP認證之基本認證——Basic(一)
  • HTTP認證之基本認證——Basic(二)
  • HTTP認證之摘要認證——Digest(一)
  • HTTP認證之摘要認證——Digest(二)

一、概述

Digest認證是為了修復基本認證協議的嚴重缺陷而設計的,秉承“絕不通過明文在網絡發送密碼”的原則,通過“密碼摘要”進行認證,大大提高了安全性。

相對於基本認證,主要有如下改進:

  • 絕不通過明文在網絡上發送密碼
  • 可以有效防止惡意用戶進行重放攻擊
  • 可以有選擇的防止對報文內容的篡改

需要注意的是,摘要認證除了能夠保護密碼之外,並不能保護其他內容,與HTTPS配合使用仍是一個良好的選擇。以下是摘要認證的具體流程圖:

看到上面出現了那麼多之前沒見過的參數,是不是有點慌(或是興奮)?別著急,這裏先給出一個概覽:

  • WWW-Authentication:用來定義使用何種方式(Basic、Digest、Bearer等)去進行認證以獲取受保護的資源
  • realm:表示Web服務器中受保護文檔的安全域(比如公司財務信息域和公司員工信息域),用來指示需要哪個域的用戶名和密碼
  • qop:保護質量,包含auth(默認的)和auth-int(增加了報文完整性檢測)兩種策略,(可以為空,但是)不推薦為空值
  • nonce:服務端向客戶端發送質詢時附帶的一個隨機數,這個數會經常發生變化。客戶端計算密碼摘要時將其附加上去,使得多次生成同一用戶的密碼摘要各不相同,用來防止重放攻擊
  • nc:nonce計數器,是一個16進制的數值,表示同一nonce下客戶端發送出請求的數量。例如,在響應的第一個請求中,客戶端將發送“nc=00000001”。這個指示值的目的是讓服務器保持這個計數器的一個副本,以便檢測重複的請求
  • cnonce:客戶端隨機數,這是一個不透明的字符串值,由客戶端提供,並且客戶端和服務器都會使用,以避免用明文文本。這使得雙方都可以查驗對方的身份,並對消息的完整性提供一些保護
  • response:這是由用戶代理軟件計算出的一個字符串,以證明用戶知道口令
  • Authorization-Info:用於返回一些與授權會話相關的附加信息
  • nextnonce:下一個服務端隨機數,使客戶端可以預先發送正確的摘要
  • rspauth:響應摘要,用於客戶端對服務端進行認證
  • stale:當密碼摘要使用的隨機數過期時,服務器可以返回一個附帶有新隨機數的401響應,並指定stale=true,表示服務器在告知客戶端用新的隨機數來重試,而不再要求用戶重新輸入用戶名和密碼了

二、剖析

1.當打開需要認證的頁面時,會彈出一個對話框,要求用戶輸入用戶名和密碼

2.使用Fidder監聽請求,可以看到在未進行認證或認證失敗的情況下,服務端會返回401 Unauthorized給客戶端,並附帶Challenge

3.輸入正確的用戶名和密碼后,瀏覽器會生成密碼摘要以及其他信息發送給服務端,服務端認證成功后,返回一些與授權會話相關的附加信息,放在Authorization-Info中。

其中,客戶端選擇的保護質量策略為authresponse就是通過計算得到的密碼摘要,具體計算方式如下(使用默認的MD5加密算法):

MD5(MD5(A1):<nonce>:<nc>:<cnonce>:<qop>:MD5(A2))

算法 A1
MD5(默認) <username>:<realm>:<password>
MD5-sess MD5(<username>:<realm>:<password>):<nonce>:<cnonce>
qop A2
auth(默認) <request-method>:<uri>
auth-int <request-method>:<uri>:MD5(<request-entity-body>)

另外,rspauth使得客戶端可以對服務器進行認證,稱為響應摘要。響應摘要的計算與請求摘要類似,但由於響應中沒有方法,而且報文實體數據有所不同,所有隻有報文主題信息A2不同。具體區別如下:

qop A2
auth(默認) :<uri>
auth-int :<uri>:MD5(<response-entity-body>)

4.當服務端隨機數過期時,再次請求認證,可以看到質詢中增加了stale=true,用戶無需再次輸入用戶名和密碼,瀏覽器會自動使用新的質詢參數進行密碼摘要的計算。

三、注意事項

1.預授權:服務端預先告知客戶端下一個隨機數是多少,使得客戶端可以直接生成正確的Authorization首部,避免了多次“請求/質詢”。常用的有一下三種方式:

  • 服務器預先在Authorization-Info成功首部中發送下一個隨機數nextnonce。雖然這種機制加快了事務處理的速度,但是它也破壞了對同一台服務器的多次請求進行管道化的功能,可能會造成很大的損失。
  • 服務器允許在一小段時間內使用同一個隨機數。這也就是我們上面剖析中使用的機制,在一定時間內使用同一個隨機數或限制某個隨機數的重用次數,當過期時,聲明stale=true。雖然這確實降低了安全性,但是重用的隨機數的生存周期是可控的,應該在安全和性能之間找到平衡。
  • 客戶端和服務器使用同步的、可預測的隨機數生成算法。

2.RFC 2617建議採用這個假想的隨機數公式:

BASE64(timestamp MD5(timestamp “:” ETag “:” private-key))

其中,timestamp是服務器產生隨機數的時間或其他不重複的值,ETag是與所請求實體有關的HTTP ETag首部的值,private-key是只有服務器知道的私鑰。

【精選推薦文章】

自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

您可能也會喜歡…