在上一期中筆者較為詳細的介紹了httpbasic認證在apache下的配置，通過簡單的實驗演示了http basic認證的基本原理。
但是，聰明的讀者很快可以發現，這種認證方式是存在很多缺陷的，具體表現如下：
1， basic認證會通過網路傳送使用者名稱和密碼，並且是以base64的方式對使用者名稱和密碼進行簡單的編碼後傳送的，而base64編碼本身非常容易被解碼，所以經過base64編碼的密碼實際上是明文傳送的。
2， 即使密碼是經過加密傳輸的，當第三方使用者仍然可以捕獲被修改過的使用者名稱和密碼，並將修改過的使用者名稱和密碼反覆多次的重放給原始伺服器，以獲得對伺服器的訪問權，basic認證沒有什麼措施可以用來防止這些重放攻擊。
3， 一些不良習慣會使得basic認證更加危險，那就是使用者由於受不了大量密碼保護的服務，會在這些不同的服務間使用相同的使用者名稱和密碼。
4， basic認證沒有提供任何針對**和作為中間人的中間節點的防護措施，它們沒有修改認證首部，但卻能夠修改報文的其餘部分，這樣就嚴重的改變了事務的本質。即basic認證沒法支援對內容或者報文本身的保護。
5， basic不支援對稱認證，即客戶端無法認證伺服器的合法性，因此客戶端很容易被釣魚到乙個非法的伺服器從而輸入了使用者名稱和密碼。
綜上，basic 認證存在很多的不足，使得一般只能用在一些非常簡單場景而不能很好的支援真正的產品級別的運用。
下面要介紹的另外一種認證，摘要認證則針對basic認證存在的諸多問題而進行的改良方案。
摘要認證時另外一種http認證協議，它試圖修復basci認證的嚴重缺陷，即進行如下改進:
1， 通過傳遞使用者名稱，密碼等計算出來的摘要來解決明文方式在網路上傳送密碼的問題。
2， 通過服務產生隨機數nonce的方式可以防止惡意使用者捕獲並重放認證的握手過程。
3， 通過客戶端產生隨機數cnonce的方式，支援客戶端對伺服器的認證。
4， 通過對內容也加入摘要計算的方式，可以有選擇的防止對報文內容的篡改。
但是，摘要認證並不是罪安全的協議，也無法滿足安全http事務的很多需求，對這些需求來說，可能使用https方式更為合適。
一，用摘要保護密碼
摘要認證的乙個改進之處是用摘要代替密碼的傳輸，遵循的基本原則是「絕對不通過網路傳送明文密碼」，而是傳送乙個密碼的摘要資訊，並且這摘要資訊是不可逆的，即無法通 過摘要資訊反推出密碼資訊。而伺服器本身是儲存這個密碼的（實際上，伺服器只需知道密碼的摘要即可），而客戶端和伺服器本身都知道這個密碼。這樣的話，伺服器可以讀取客戶端的摘要和本身知道的密碼進行同樣計算得出的摘要進行比較，若匹配，則驗證通過。
摘要是對資訊主體的濃縮，摘要是一種單向函式，主要用於將無限的輸入值轉為有限的濃縮輸出值，如md5，則是將任意長度的位元組系列轉換為乙個128位的摘要。md5輸出的128位的摘要通常會寫出32個十六進製制的字元，每個字元表示4個bit。
二，用隨機數防止重放攻擊
使用單向摘要就無需以明文形式傳送密碼了，可以只傳送密碼的摘要，並且可以確信，沒有哪個惡意使用者能輕易的從摘要中解碼出原始密碼。
但是，摘要被截獲也可能跟密碼一起好用，為了防止重放攻擊的傳送，伺服器可以向客戶端傳送乙個稱為隨機數nonce的特殊令牌，這個數會經常發生變化(可能是每毫秒，或者每次認證都發生變化，具體由伺服器控制)，客戶端在計算摘要之前要先將這個隨機數附加到密碼上去。這樣，在密碼中加入隨機數就會使得摘要隨著隨機數的每次變化而變化，記錄下的密碼摘要只對特定的隨機數有效，而沒有密碼的話，攻擊者就無法計算出正確的摘要，這樣就可以防止重放攻擊的發生。
摘要認證要求使用隨機數，隨機數是在www-authenticate伺服器質詢響應中從伺服器傳輸給客戶端的。
三，摘要認證的握手過程
1， 第一次客戶端請求的時候，伺服器產生乙個隨機數nonce，伺服器將這個隨機數放在www-authenticate響應頭，與伺服器支援的認證演算法列表，認證的域realm一起傳送給客戶端，如下例子：
2， 客戶端發現是401響應，表示需要進行認證，則彈出讓使用者輸入使用者名稱和密碼的認證視窗，客戶端選擇乙個演算法，計算出密碼和其他資料的摘要，將摘要放到authorization的請求頭中傳送給伺服器，如果客戶端要對伺服器也進行認證，這個時候，可以傳送客戶端隨機數cnonce。如下例子：
nonce=」 66c4ef58da7cb956bd04233fbb64e0a4」 //伺服器端的隨機數一起帶回
uri=」/cgi-bin/checkout?a=b」 //必須跟請求行一致
qop=」auth」 //保護質量引數
nc=0000001
cnonce=」***xx234132543strwerr65sgdrftdfytryts」 //客戶端隨機數，用於對稱校驗
response=」 abc4ef58da7cb956bd04345fbb64e0a4」//最終摘要
3， 服務接受摘要，選擇演算法以及掌握的資料，重新計算新的摘要跟客戶端傳輸的摘要進行比較，驗證是否匹配，若客戶端反過來用客戶端隨機數對伺服器進行質詢，就會建立客戶端摘要，服務可以預先將下乙個隨機數計算出來，提前傳遞給客戶端，通過authentication-info傳送下乙個隨機數。如下例子：
四，摘要的計算
在說明如何計算摘要之前，先說明參加摘要計算的資訊塊。資訊塊主要有兩種：
1，表示與安全相關的資料的a1。
a1中的資料時密碼和受保護資訊的產物，它包括使用者名稱，密碼，保護域和隨機數等內容，a1只涉及安全資訊，與底層報文自身無關。
若演算法是：md5
則a1=::
若演算法是：md5-sess
則a1=md5(::)::
2，表示與報文相關的資料的a2.
a2表示是與報文自身相關的資訊，比如url，請求反覆和報文實體的主體部分，a2加入摘要計算主要目的是有助於防止反覆，資源或者報文被篡改。
若qop未定義或者auth：
a2=:
若qop為auth:-int
a2=::md5()
下面定義摘要的計算規則：
若qop沒有定義：
摘要response=md5(md5(a1)::md5(a2))
若qop為auth:
摘要response=md5(md5(a1):::::md5(a2))
若qop為auth-int:
摘要response= md5(md5(a1):::::md5(a2))
五，隨機數的生成
rfc2617建議採用這個假想的隨機數公式：
nonce = base64(time-stamp md5(time-stamp 「:」 etag 「:」 private-key))
其中:time-stamp是伺服器產生的時間戳或者其他不會重複的序列號，etag是與所請求實體有關的http etag首部的值，priviate-key是只有伺服器知道的資料。
這樣，伺服器就可以收到客戶端的認證首部之後重新計算雜湊部分，如果結果與那個首部的隨機數不符，或者是時間戳的值不夠新，就可以拒絕請求，伺服器可以通過這種方式來限制隨機數的有效持續時間。
包括了etag可以防止對已經更新資源版本的重放請求。注意：在隨機數中包含客戶端ip，伺服器好像就可以限制原來獲取此隨機數的客戶端重用這個隨機數了，但這會破壞**集群的工作，使用**集群時候，來自單個使用者的多條請求通常會經過不同的**進行傳輸，而且ip位址欺騙實現起來也不複雜。
http摘要認證
摘要 認證步驟 1.客戶端訪問乙個受http摘要認證保護的資源。2.伺服器返回401狀態以及nonce等資訊，要求客戶端進行認證。3.客戶端將以使用者名稱，密碼，nonce值，http方法,和被請求的uri為校驗值基礎而加密 預設為 md5演算法 的摘要資訊返回給伺服器。認證必須的五個情報 real...
HTTP 摘要認證
基本認證便捷靈活，但極不安全。使用者名稱和密碼都是以明文形式傳送的，也沒有採取任何措施防止對報文的篡改。安全使用基本認證的唯一方式就是將其與 ssl 配合使用。摘要認證是另一種 http 認證協議，它與基本認證相容，但卻更為安全。摘要認證試圖修復基本認證協議的嚴重缺陷。具體來說，摘要認證進行了如下改...
HTTP 基本認證，摘要認證，擴充套件HTTP認證
http請求報頭 authorization http響應報頭 www authenticate http認證 基於質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm，通過提供使用...