前端學HTTP之摘要認證

前面的話

　　上一篇介紹的基本認證便捷靈活，但極不安全。用戶名和密碼都是以明文形式傳送的，也沒有采起任何措施防止對報文的篡改。安全使用基本認證的惟一方式就是將其與SSL配合使用

　　摘要認證與基本認證兼容，但卻更爲安全。本文將詳細介紹紹摘要認證的原理和實際應用

 

工做原理

　　摘要認證是另外一種HTTP認證協議，它試圖修復基本認證協議的嚴重缺陷。具體來講，摘要認證進行了以下改進：永遠不會以明文方式在網絡上發送密碼；能夠防止惡意用戶捕獲並重放認證的握手過程；能夠有選擇地防止對報文內容的篡改；防範其餘幾種常見的攻擊方式

　　摘要認證並非最安全的協議，並不能知足安全HTTP事務的不少需求。對這些需求來講，使用傳輸層安全(Transport Layer Security, TLS)和安全HTTP(Secure HTTP, HTTPS)協議更爲合適一些

　　但摘要認證比它要取代的基本認證強大不少。與不少建議其餘因特網服務使用的經常使用策略相比，(好比曾建議LDAP、POP和IMAP使用的CRAM-MD5)，摘要認證也要強大不少

　　迄今爲止，摘要認證尚未被普遍應用。但因爲基本認證存在固有的安全風險，HTTP設計者曾在RFC 2617中建議：「在可行的狀況下應該將目前在用的全部使用基本認證的服務，儘快地轉換爲摘要認證方式」

　　摘要認證遵循的箴言是「毫不經過網絡發送密碼」。客戶端不會發送密碼，而是會發送一個「指紋」或密碼的「摘要」，這是密碼的不可逆擾碼。客戶端和服務器都知道這個密碼，所以服務器能夠驗證所提供的摘要是否與密碼相匹配。只拿到摘要的話，除了將全部的密碼都拿來試試以外，沒有其餘方法能夠找出摘要是來自哪一個密碼

　　經過下圖能夠了解摘要認證的工做原理

　　在圖a中，客戶端請求了某個受保護文檔

　　在圖b中，在客戶端可以證實其知道密碼從而確認其身份以前，服務器拒絕提供文檔。服務器向客戶端發起質詢，詢問用戶名和摘要形式的密碼

　　在圖c中，客戶端傳遞了密碼的摘要，證實它是知道密碼的。服務器知道全部用戶的密碼，所以能夠將客戶提供的摘要與服務器本身計算獲得的摘要進行比較，以驗證用戶是否知道密碼。另外一方在不知道密碼的狀況下，很難僞造出正確的摘要

　　在圖d中，服務器將客戶端提供的摘要與服務器內部計算出的摘要進行對比。若是匹配，就說明客戶端知道密碼。能夠設置摘要函數，使其產生不少數字，讓人不可能幸運地猜中摘要。服務器進行了匹配驗證以後，會將文檔提供給客戶端——整個過程都沒有在網絡上發送密碼

【單向摘要】

　　摘要是「對信息主體的濃縮」，它是一種單向函數，主要用於將無限的輸入值轉換爲有限的濃縮輸出值。常見的摘要函數MD5，會將任意長度的字節序列轉換爲一個128位的摘要

　　對這些摘要來講，最重要的是若是不知道密碼的話，要想正確地猜出發送給服務器的摘要將是很是困難的。一樣，若是有摘要，想要判斷出它是由無數輸入值中的哪個產生的，也是很是困難的

　　MD5輸出的128位的摘要一般會被寫成32個十六進制的字符，每一個字符表示4位。下表中給出了幾個示例輸入的MD5摘要

　　有時也將摘要函數稱爲加密的校驗和、單向散列函數或指紋函數

【用隨機數防止重放攻擊】

　　使用單向摘要就無需以明文形式發送密碼了，能夠只發送密碼的摘要，並且能夠確信，沒有哪一個惡意用戶能輕易地從摘要中解碼出原始密碼

　　可是，僅僅隱藏密碼並不能避免危險，由於即使不知道密碼，別有用心的人也能夠截獲摘要，並一遍遍地重放給服務器。摘要和密碼同樣好用

　　爲防止此類重放攻擊的發生，服務器能夠向客戶端發送一個稱爲隨機數(nonce)的特殊令牌，這個數會常常發生變化(多是每毫秒，或者是每次認證都變化)。客戶端在計算摘要以前要先將這個隨機數令牌附加到密碼上去

　　在密碼中加入隨機數就會使摘要隨着隨機數的每一次變化而變化。記錄下的密碼摘要只對特定的隨機值有效，而沒有密碼的話，攻擊者就沒法計算出正確的摘要，這樣就能夠防止重放攻擊的發生

　　摘要認證要求使用隨機數，由於這個小小的重放弱點會使未隨機化的摘要認證變得和基本認證同樣脆弱。隨機數是在WWW-Authenticate質詢中從服務器傳送給客戶端的

【握手機制】

　　HTTP摘要認證協議是一種升級版的認證方式，所用首部與基本認證相似。它在傳統首部中添加一些新的選項，還添加了一個新的可選首部Authorization-Info

　　下圖描述了簡化的摘要認證三步握手機制

　　在第(1)步中，服務器會計算出一個隨機數

　　在第(2)步中，服務器將這個隨機數放在WWW-Authenticate質詢報文中，與服務器所支持的算法列表一同發往客戶端

　　在第(3)步中，客戶端選擇一個算法，計算出密碼和其餘數據的摘要

　　在第(4)步中，將摘要放在一條Authorization報文中發回服務器。若是客戶端要對服務器進行認證，能夠發送客戶端隨機數

　　在第(5)步中，服務器接收摘要、選中的算法以及支撐數據，計算出與客戶端相同的摘要。而後服務器將本地生成的摘要與網絡傳送過來的摘要進行比較，驗證其是否匹配。若是客戶端反過來用客戶端隨機數對服務器進行質詢，就會建立客戶端摘要。服務器能夠預先將下一個隨機數計算出來，提早將其傳遞給客戶端，這樣下一次客戶端就能夠預先發送正確的摘要了

　　這些信息中不少是可選的，並且有默認值

　　下圖中對比了基本認證和摘要認證的工做原理

摘要算法

　　摘要認證的核心就是對公共信息、保密信息和有時限的隨機值這個組合的單向摘要

　　摘要是根據由單向散列函數H(rf)和摘要KD(s,d)組成的一對函數，其中s表示密碼，d表示數據；和一個包含了安全信息的數據塊，包括密碼，稱爲A1；以及一個包含了請求報文中非保密屬性的數據塊，稱爲A2這三個組件計算出來的。H和KD處理兩塊數據A1和A2，產生摘要

　　摘要認證支持對各類摘要算法的選擇。RFC 2617建議的兩種算法爲MD5和MD5-sess(「sess」表示會話)，若是沒有指定其餘算法，默認算法爲MD5

　　無論使用的是MD5仍是MD5-sess，都會用函數H來計算數據的MD5，用摘要函數KD來計算以冒號鏈接的密碼和非保密數據的MD5

H(<data>) = MD5(<data>)
KD(<secret>,<data>) = H(concatenate(<secret>:<data>))

　　被稱爲A1的數據塊是密碼和受保護信息的產物，它包含有用戶名、密碼、保護域和隨機數等內容。A1只涉及安全信息，與底層報文自身無關。A1會與H、KD和A2一同用於摘要計算

　　RFC 2617根據選擇的算法定義了兩種計算A1的方式

　　一、MD5

　　爲每條請求運行單向散列函數。A1是由冒號鏈接起來的用戶名、域以及密碼三元組

　　二、MD5-sess

　　只在第一次WWW-Authenticate握手時運行一次散列函數。對用戶名、域和密碼進行一次CPU密集型散列，並將其放在當前隨機數和客戶端隨機數(cnonce)的前面

　　數據塊A2表示的是與報文自身有關的信息，好比URL、請求方法和報文實體的主體部分。A2有助於防止方法、資源或報文被篡改。A2會與H、KD和A1一塊兒用於摘要的計算

　　RFC 2617根據所選擇的保護質量(qop)，爲A2定義了兩種策略

　　第一種策略只包含HTTP請求方法和URL。當qop="auth"時使用這種策略，這是默認的狀況

　　第二種策略添加了報文實體的主體部分，以提供必定程度的報文完整性檢測。qop="auth-int"時使用

　　request-method是HTTP的請求方法。uri-directive-value是請求行中的請求URI。多是個"*"、absoluteURL或者abs_path，但它必須與請求URI一致。若是請求URI是absoluteURL，它必須是個絕對URL

　　RFC 2617定義了兩種給定了H、KD、A1和A2以後，計算摘要的方式

　　第一種方式要與老規範RFC 2069兼容，在沒有qop選項的時候使用。它是用保密信息和隨機報文數據的散列值來計算摘要的

　　第二種方式是如今推薦使用的方式——這種方式包含了對隨機數計算和對稱認證的支持。只要qop爲auth或auth-int，就要使用這種方式。它向摘要中添加了隨機計數、qop和cnonce數據

　　客戶端響應對保護空間的WWW-Authenticate質詢時，會啓動一個此保護空間的認證會話(與受訪問服務器的標準根結合在一塊兒的域就定義了一個「保護空間」)

　　在客戶端收到另外一條來自保護空間的任意一臺服務器的WWW-Authenticate質詢以前，認證會話會一直持續。客戶端應該記住用戶名、密碼、隨機數、隨機數計數以及一些與認證會話有關的隱晦值，以便未來在此保護空間中構建請求的 Authorization首部時使用

　　隨機數過時時，即使老的Authorization首部所包含的隨機數再也不新鮮了，服務器也能夠選擇接受其中的信息。服務器也能夠返回一個帶有新隨機數的401響應，讓客戶端重試這條請求，指定這個響應爲Stale=true，表示服務器在告知客戶端用新的隨機數來重試，而再也不從新提示輸入新的用戶名和密碼了

【預受權】

　　在普通的認證方式中，事務結束以前，每條請求都要有一次請求/質詢的循環，如圖a

　　若是客戶端事先知道下一個隨機數是什麼，就能夠取消這個請求/質詢循環，這樣客戶端就能夠在服務器發出請求以前，生成正確的Authorization首部了。若是客戶端能在服務器要求它計算Authorization首部以前將其計算出來，就能夠預先將Authorization首部發送給服務器，而不用進行請求/質詢了。圖b顯示了這種方式對性能的影響
 
　　預受權對基本認證來講並不重要，並且很常見。瀏覽器一般會維護一些客戶端數據庫以存儲用戶名和密碼。一且用戶與某站點進行了認證，瀏覽器一般會爲後繼對那個URL的請求發送正確的Authorization首部

　　因爲摘要認證使用了隨機數技術來破壞重放攻擊，因此對摘要認證來講，預受權要稍微複雜一些。服務器會產生任意的隨機數，因此在客戶端收到質詢以前，不必定總能斷定應該發送什麼樣的Authorization首部

　　摘要認證在保留了不少安全特性的同時，還提供了幾種預受權方式。這裏列出了三種可選的方式，經過這些方式，客戶端無需等待新的WWW-Authenticate質詢，就能夠得到正確的隨機數

　　一、服務器預先在Authentication-Info成功首部中發送下一個隨機數

　　能夠在Authentication-Info成功首部中將下一個隨機數預先提供給客戶端。這個首部是與前一次成功認證的200 OK響應一同發送的

　　Authentication-Info: nextnonce="<nonce-value>"

　　有了下一個隨機數，客戶端就能夠預先發布Authorization首部了

　　儘管這種預受權機制避免了請求/質詢循環，加快了事務處理的速度，但實際上它也破壞了對同一臺服務器的多條請求進行管道化的功能，由於在發佈下一條請求以前，必定要收到下一個隨機值才行。而管道化是避免延遲的一項基本技術，因此這樣可能會形成很大的性能損失

　　二、服務器容許在一小段時間內使用同一個隨機數

　　第二種方法是在有限的次數內重用隨機數。好比，服務器可能容許將某個隨機數重用5次，或者重用10秒

　　在這種狀況下，客戶端能夠隨意發佈帶有Authorization首部的請求，並且因爲隨機數是事先知道的，因此還能夠對請求進行管道化。隨機數過時時，服務器要向客戶端發送 401 Unauthorized 質詢，並設置WWW-Authenticate:stale=true指令

WWW-Authenticate:Digest realm="<realm-value>" nonce="<nonce-value>" stale=true

　　重用隨機數使得攻擊者更容易成功地實行重放攻擊。雖然這確實下降了安全性，但重用的隨機數的生存期是可控的，從嚴格禁止重用到較長時間的重用，因此應該能夠在安全和性能間找到平衡

　　此外，還能夠經過其餘一些特性使重放攻擊變得更加閒難，其中就包括增置計數器和IP地址測試。但這些技術只能使攻擊的實施更加麻煩，並不能消除由此帶來的安全隱患

　　三、客戶端和服務器使用同步的、可預測的隨機數生成算法

　　第三種方法是採用時間同步的隨機數生成算法，客戶端和服務器可根據共享的密鑰，生成第三方沒法輕易預測的、相同的隨機數序列(好比安全ID卡)

【隨機數】

　　隨機數的內容不透明，並且與實現有關。但性能、安全性和便捷性的優劣都取決於明智的選擇

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

BASE64(time-stamp H(time-stamp "" ETag ":" private-key))

　　其中time-stamp是服務器產生的時間或其餘不會重複的值，ETag是與所請求實體有關的HTTP ETag首部的值，private-key是隻有服務器知道的數據

　　有了這種形式的隨機數，服務器就能夠在收到客戶端的認證首部以後從新計算散列部分，若是結果與那個首部的隨機數不符，或者時間戳的值不夠新，就拒絕請求。服務器能夠經過這種方式來限制隨機數的有效持續時間

　　包含Etag能夠防止對已更新資源版本的重放請求。在隨機數中包含客戶端的IP地址，服務器好像就能夠限制原來得到此隨機數的客戶端重用這個隨機數了，但這會破壞代理集羣的工做。使用代理集羣時，來自單個用戶的多條請求一般會通過不一樣的代理進行傳輸，並且IP地址欺騙實現起來也不是很難

　　實現能夠選擇不接受之前使用過的隨機數或摘要，以防止重放攻擊。實現也能夠選擇爲POST或PUT請求使用一次性的隨機數或摘要，爲GET請求使用時間戳

【對稱認證】

　　RFC 2617擴展了摘要認證機制，容許客戶端對服務器進行認證。這是經過提供客戶端隨機值來實現的，服務器會根據它對共享保密信息的正確瞭解生成正確的響應摘要。而後，服務器在Authorization-Info首部中將此摘要返回給客戶端

　　這種對稱認證方式被標準化爲RFC 2617。爲了與原有RFC 2069標準後向兼容，它是可選的，但因爲它提供了一些重要的安全提高機制，強烈推薦現今全部的客戶端和服務器都要實現所有RFC 2617特性。特別是，只要提供了qop指令，就要求執行對稱認證，而沒有qop指令時則不要求執行對稱認證

　　響應摘要的計算方法與請求摘要相似，但因爲響應中沒有方法，並且報文實體數據有所不一樣，因此只有報文主體信息A2不一樣
　　下表是請求摘要中A2的定義

　　下表是響應摘要中A2的定義

　　cnonce值和nc值必須是本報文所響應的客戶端請求中的相應值。若是指定了gop="auth"或qop="auth-int"，就必須提供響應auth、cnonce和nonce計數指令

 

加強保護

　　能夠在三種摘要首部中提供qop字段：WWW-Authenticate、Authorization和Authentication-Info

　　經過qop字段，客戶端和服務器能夠對不一樣類型及質詢的保護進行協商。好比，即使會嚴重下降傳輸速度，有些事務可能也要檢査報文主體的完整性

　　服務器首先在WWW-Authenticate首部輸出由逗號分隔的qop選項列表。而後客戶端從中選擇一個它支持且知足其需求的選項，並將其放在Authorization的qop字段中回送給服務器

　　qop字段是可選的，但只是在後向兼容原有RFC 2069規範的狀況下才是可選的。現代全部的摘要實現都應該支持qop選項

RFC 2617定義了兩種保護質量的初始值：表示認證的auth，帶有報文完整性保護的認證auth-int。未來可能還會出現其餘qop選項

　　若是使用了完整性保護(qop="auth-int")，H(實體的主體部分)就是對實體主體部分，而不是報文主體部分的散列。對於發送者，要在應用任意傳輸編碼方式以前計算；而對於接收者，則應在去除全部傳輸編碼以後計算。注意，對於任何含有多部份的內容類型來講，多部分的邊界和每部分中嵌入的首部都要包含在內

　　基本認證和摘要認證協議都包含了WWW-Authenticate首部承載的受權質詢、Authorization首部承載的受權響應。摘要認證還添加了可選的Authorization-info首部，這個首部是在成功認證以後發送的，用於實現三步握手機制，並傳送下一個隨機數。下表給出了基本認證和摘要認證的首部

實際問題

　　使用摘要認證時須要考慮如下幾個實際問題

【多重質詢】

　　服務器能夠對某個資源發起多重質詢。好比，若是服務器不瞭解客戶端的能力，就能夠既提供基本認證質詢，又提供摘要認證質詢。客戶端面對多重質詢時，必須以它所支持的最強的質詢機制來應答

　　質詢自身可能會包含由逗號分隔的認證參數列表。若是WWW-Authenticate或Proxy-Authenticate首部包含了多個質詢，或者提供了多個WWW-Authenticate首部，用戶Agent代理在解析WWW-Authenticate或Proxy-Authenticate首部字段值時就要特別當心

　　[注意]不少瀏覽器只支持基本認證，要求這是提交給它的第一種認證機制

　　在提供了認證選項範圍的狀況下，安全問題上就會存在明顯的「最薄弱環節」。只有當基本認證是最低可接受認證方式時，服務器才應該包含它，並且管理員還應該警告用戶，即便運行了不一樣層次安全措施，系統間使用相同密碼也存在必定危險性

【差錯處理】

　　在摘要認證中，若是某個指令或其值使用不當，或者缺乏某個必要指令，就應該使用響應400 Bad Request

　　若是請求的摘要不匹配，就應該記錄一次登陸失敗。某客戶端連續屢次失敗可能說明有攻擊者正在猜想密碼

　　認證服務器必定要確保URI指令指定的資源與請求行中指定的資源相同。若是不一樣，服務器就應該返回400 Bad Request錯誤。這多是一種攻擊的跡象，所以服務器設計者可能會考慮將此類錯誤記錄下來。這個字段包含的內容與請求URL中的內容是重複的，用來應對中間代理可能對客戶端請求進行的修改。這個通過修改(但估計語義是等價的)的請求計算後獲得的摘要可能會與客戶端計算出的摘要有所不一樣

【保護空間】

　　域值，與被訪問服務器的標準根URL結合在一塊兒，定義了保護空間

　　經過域能夠將服務器上的受保護資源劃分爲一組保護空間，每一個空間都有本身的認證機制和(或)受權數據庫。域值是一個字符串，一般由原始服務器分配，可能會有認證方案特有的附加語義

　　[注意]可能會有多個受權方案相同，而域不一樣的質詢

　　保護空間肯定能夠自動應用證書的區域。若是前面的某條請求已被受權，在一段時間內，該保護空間中全部其餘請求均可以重用同一個證書，時間的長短由認證方案、參數和(或)用戶喜愛來決定。除非認證方案進行了其餘定義，不然單個保護空間是不能擴展到其服務器範圍以外的

　　對保護空間的具體計算取決於認證機制

　　在基本認證中，客戶端會假定請求URI中或其下的全部路徑都與當前的質詢處於同一個保護空間內。客戶端能夠預先提交對此空間中資源的認證，無需等待來自服務器的另外一條質詢

　　在摘要認證中，質詢的WWW-Authenticate:domain字段對保護空間做了更精確的定義。domain字段是一個用引號括起來的、中間由空格分隔的URI列表。一般認爲，domain列表中的全部URI和邏輯上處於這些前綴之下的全部URI，都位於同一個保護空間中。若是沒有domain字段，或者此字段爲空，質詢服務器上的全部URI就都在保護空間內

【重寫 URI】

　　代理能夠經過改變URI語法，而不改變所描述的實際資源的方式來重寫URI

　　能夠對主機名進行標準化，或用IP地址來取代

　　能夠用「%」轉義形式來取代嵌入的字符

　　若是某類型的一些附加屬性不會影響從特定原始服務器上獲取資源，就能夠將其附加或插入到URI中

　　代理可修改URI，並且摘要認證會檢査URI值的完整性，因此若是進行了任意一種修改，摘要認證就會被破壞

【緩存】

　　共享的緩存收到包含Authorization首部的請求和轉接那條請求產生的響應時，除非響應中提供了下列兩種Cache-Control指令之一，不然必定不能將那條響應做爲對任何其餘請求的應答使用

　　一、若是原始響應中包含有Cache-Control指令must-revalidate，緩存能夠在應答後繼請求時使用那條響應的實體部分。但它首先要用新請求的請求首部，與原始服務器再次進行驗證，這樣原始服務器才能夠對新請求進行認證

　　二、若是原始響應中包含有Cache-Control指令public，在對任意後繼請求的應答中均可以返回響應的實體部分

 

安全考慮

【首部篡改】

　　爲了提供一個簡單明瞭的防首部篡改系統，要麼就得進行端到端的加密，要麼就得對首部進行數字簽名——最好是二者的結合。摘要認證的重點在於提供一種防篡改認證機制，但並不必定要將這種保護擴展到數據上去。具備必定保護級別的首部只有WWW-Authenticate和Authorization

【重放攻擊】

　　在當前的上下文中，重放攻擊指的就是有人將從某個事務中竊取的認證證書用於另外一個事務。儘管對GET請求來講這也是個問題，但爲POST和PUT請求提供一種簡單的方式來避免重放攻擊纔是很是必要的。在傳輸表單數據的同時，成功重放原先用過的證書會引起嚴重的安全問題

　　所以，爲了使服務器可以接受「重放的」證書，還必須重複發送隨機數。緩解這個問題的方法之一就是讓服務器產生的隨機數包含根據客戶端IP地址、時間戳，資源Etag和私有服務器密鑰算出的摘要。這樣，IP地址和一個短小超時值的組合就會給攻擊者形成很大的障礙

　　但這種解決方案有一個很重要的缺陷。用客戶端IP地址來建立隨機數會破壞通過代理集羣的傳輸。在這類傳輸中，來自單個用戶的多條請求可能會穿過不一樣的代理。並且，IP欺騙也並不難實現

　　一種能夠徹底避免重放攻擊的方法就是爲每一個事務都使用一個惟一的隨機數。在這種實現方式中，服務器會爲每一個事務發佈惟一的隨機數和一個超時值。發佈的隨機數只對指定的事務有效，並且只在超時值的持續區間內有效。這種方式會增長服務器的負擔，但這種負擔可忽略不計

【多重認證機制】

　　服務器支持多重認證機制(好比基本認證和摘要認證)時，一般會在WWW-Authenticate首部提供選項。因爲沒有要求客戶端選擇功能最強的認證機制，因此獲得的認證效果就和功能最弱的認證方案差很少

　　要避免出現這個問題，最直接的方法就是讓客戶端老是去選擇可用認證方案中功能最強的那個。若是沒法實現，惟一的選擇就是使用一個只維護最強認證方案的代理服務器，但只有在已知全部客戶端都支持所選認證方案的區域中才能採用這種方式

【詞典攻擊】

　　詞典攻擊是典型的密碼猜想型攻擊方式。惡意用戶對某個事務進行竊聽，並對隨機數/響應對使用標準的密碼猜想程序。若是用戶使用的是相對比較簡單的密碼，並且服務器使用的也是簡單的隨機數，它極可能會找到匹配項。若是沒有密碼過時策略，只要有足夠的時間和破解密碼所需的一次性費用，就很容易蒐集到足夠多的密碼，形成實質性的破壞

　　除了使用複雜的相對難以破譯的密碼和合適的密碼過時策略以外，確實沒有什麼好的方法能夠解決這個問題

【惡意代理攻擊和中間人攻擊】

　　如今不少因特網流量都會在這個或那個地方流經某個代理。隨着重定向技術和攔截代理的出現，用戶甚至都意識不到他的請求穿過了某個代理。若是這些代理中有一個是惡意的或者容易被入侵的，就會使客戶端置於中間人攻擊之下

　　這種攻擊能夠採用竊聽的形式，也能夠刪除提供的全部選項，用最薄弱的認證策略(好比基本認證)來取代現有的認證機制，對其進行修改

　　入侵受信代理的方式之一就是使用其擴展接口。有時代理會提供複雜的編程接口，能夠爲這類代理編寫一個擴展(好比，plug-in)來攔截流量並對其進行修改。不過，數據中心和代理自身提供的安全性使得經過惡意plug-in進行中間人攻擊的可能性變得很渺茫

　　沒有什麼好辦法能夠解決這個問題。可行的解決方案包括由客戶端提供與認證功能有關的可見線索，對客戶端進行配置使其老是使用可用認證策略中功能最強的那一種等等。但即便使用的是最強大的認證策略，客戶端仍然很容易被竊聽。防止這些攻擊惟一簡便的方式就是使用SSL

【選擇明文攻擊】

　　使用摘要認證的客戶端會用服務器提供的隨機數來生成響應。但若是中間有一個被入侵的或惡意的代理在攔截流量(或者有個惡意的原始服務器)，就能夠很容易地爲客戶端的響應計算提供隨機數。使用已知密鑰來計算響應能夠簡化響應的密碼分析過程。這種方式被稱爲選擇明文攻擊(chosen plaintext attack)。選擇明文攻擊有如下幾種變體形式

　　一、預先計算的詞典攻擊

　　這是詞典攻擊和選擇明文攻擊的組合。首先，發起攻擊的服務器會用預先肯定的隨機數和常見密碼的變化形式產生一組響應，建立一個詞典。一旦有了規模可觀的詞典，攻擊服務器或代理就能夠完成對流量的封鎖，向客戶端發送預先肯定的隨機數。攻擊者從客戶端獲得一個響應時，會搜索生成的詞典，尋找匹配項。若是有匹配項，攻擊者就捕獲了這個用戶的密碼

　　二、批量暴力型攻擊

　　批量暴力型攻擊的不一樣之處在於計算密碼的方式。它沒有試圖去匹配預先計算出來的摘要，而是用一組機器枚舉了指定空間內全部可能的密碼。隨着機器運行速度變得愈來愈快，暴力型攻擊的可行性也變得愈來愈強了

　　總之，這些攻擊所形成的威脅是很容易應對的。防止這些攻擊的一種方法就是配置客戶端使用可選的cnonce指令，這樣響應就是基於客戶端的判斷產生的，而不是用服務器提供的隨機數(這個隨機數可能會被攻擊者入侵)產生的。經過這種方法，再結合一些強制使用合理強密碼的策略，以及一個好的密碼過時策略，就能夠徹底消除選擇明文攻擊的威脅

【存儲密碼】

　　摘要認證機制將對比用戶的響應與服務器內部存儲的內容——一般就是用戶名和H(A1)元組對，其中H(A1)是從用戶名、域和密碼的摘要中導出的

　　與Unix機器中傳統的密碼文件不一樣，若是摘要認證密碼文件被入侵了，攻擊者立刻就可以使用域中全部文件，不須要再進行解碼了

　　消除這個問題的方法包括：就像密碼文件中包含的是明文密碼同樣來保護它；確保域名在全部域中是惟一的。這樣，若是密碼文件被入侵，所形成的破壞也只侷限於一個特定的域中。包含主機和domain的全路徑域名就能夠知足這個要求

　　儘管摘要認證提供的解決方案比基本認證要強壯且安全得多，但它並無爲內容的安全提供任何保證——真正安全的事務只有經過SSL才能實現

 

指令描述

　　下表中根據RFC 2617描述，對WWW-Authenticate指令進行了詳細說明

　　下表對Authentication指令進行了詳細說明

　　下表對Authentication-Info指令進行了詳細說明