HTTP認證模式：Basic & Digest

一. Basic 認證

　　客戶端以“ : ”連接用戶名和密碼后，再經(jīng)BASE64加密通過Authorization請求頭發(fā)送該密文至服務端進行驗證，每次請求都需要重復發(fā)送該密文。可見Basic認證過程簡單，安全性也低，存在泄露個人賬號信息以及其他諸多安全問題。以下僅為原理演示，不代表真實情況：

1. 客戶端向服務器請求數(shù)據(jù):

   GET / HTTP/1.1
   Host: www.myrealm.com

2. 服務端向客戶端發(fā)送驗證請求401：

   HTTP/1.1 401 Unauthorised
   Server: bfe/1.0.8.18
   WWW-Authenticate: Basic realm="myrealm.com"
   Content-Type: text/html; charset=utf-8

3. 客戶端收到401返回值后，將自動彈出一個登錄窗口，等待用戶輸入用戶名和密碼

4. 將“用戶名:密碼”進行BASE64加密后發(fā)送服務端進行驗證：

   GET / HTTP/1.1
   Host: www.myrealm.com
   Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx

5. 服務端取出Authorization請求頭信息進行解密，并與用戶數(shù)據(jù)庫進行對比判斷是否合法，合法將返回200 OK。RFC 2617 規(guī)格中Basic認證不發(fā)送Authentication-Info頭部，Authentication-Info頭部是Digest認證中新增的

 1 <?php 2   if (!isset($_SERVER['PHP_AUTH_USER'])) { 3     header('WWW-Authenticate: Basic realm="My Realm"'); 4     header('HTTP/1.0 401 Unauthorized'); 5     echo 'Text to send if user hits Cancel button'; 6     exit; 7   } else { 8     echo "<p>Hello {$_SERVER['PHP_AUTH_USER']}.</p>"; 9     echo "<p>You entered {$_SERVER['PHP_AUTH_PW']} as your password.</p>";10   }

二. Digest 認證

　　Digest認證試圖解決Basic認證的諸多缺陷而設計，用戶密碼在整個認證過程中是個關鍵性要素。

　　下為服務端發(fā)送的Digest認證響應頭部實例及各指令含義說明：PHP官方文檔中發(fā)送WWW-Authenticate頭部時各指令之間用了空格，在Chrome下是不會彈出認證對話框的，應該換成”, “或”,“

WWW-Authenticate: Digest realm="Restricted area", qop="auth,auth-int", nonce="58e8e52922398", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", algorithm="MD5"

• WWW-Authenticate：服務端發(fā)送的認證質詢頭部

• Authentication-Info：服務端發(fā)送的認證響應頭部，包含nextnonce、rspauth響應摘要等

• realm：授權域，至少應該包含主機名

• domain：授權訪問URIs列表，項與項之間以空格符分隔

• qop：質量保護，值為auth或auth-int或[token]，auth-int包含對實體主體做完整性校驗

• nonce：服務端產(chǎn)生的隨機數(shù)，用于增加摘要生成的復雜性，從而增加破解密碼的難度，防范“中間人”與“惡意服務器”等***類型，這是相對于不使用該指令而言的；另外，nonce本身可用于防止重放***，用于實現(xiàn)服務端對客戶端的認證。RFC 2617 建議采用這個隨機數(shù)計算公式：nonce = BASE64(time-stamp MD5(time-stamp “:” ETag “:” private-key))，服務端可以決定這種nonce時間有效性，ETag(URL對應的資源Entity Tag，在CGI編程中通常需要自行生成ETag和鑒別，可用于鑒別URL對應的資源是否改變，區(qū)分不同語言、Session、Cookie等)可以防止對已更新資源版本(未更新無效，故需要設定nonce有效期)的重放請求，private-key為服務端私有key

• opaque：這是一個不透明的數(shù)據(jù)字符串，在盤問中發(fā)送給客戶端，客戶端會將這個數(shù)據(jù)字符串再發(fā)送回服務端器。如果需要在服務端和客戶端之間維護一些狀態(tài)，用nonce來維護狀態(tài)數(shù)據(jù)是一種更容易也更安全的實現(xiàn)方式

• stale：nonce過期標志，值為true或false

• algorithm：摘要算法，值為MD5或MD5-sess或[token]，默認為MD5

　　下為客戶端發(fā)送的Digest認證頭請求部實例及各指令含義說明：

Authorization: Digest username="somename", realm="Restricted area", nonce="58e8e52922398", uri="/t.php", response="9c839dde909d270bc5b901c7f80f77d5", opaque="cdce8a5c95a1427d74df7acbf41c9ce0", qop="auth", nc=00000001, cnonce="9c30405c3a67a259"

• cnonce：客戶端產(chǎn)生的隨機數(shù)，用于客戶端對服務器的認證。由于“中間人”與“惡意服務器”等***方式的存在，導致一個特意選擇而非隨機唯一的nonce值傳給客戶端用于摘要的計算成為可能，使得“選擇性明文***”可能奏效，最后用戶密碼泄露。因此與nonce一樣，cnonce可用于增加摘要生成的復雜性，從而增加破解密碼的難度，也就保證了對服務端的認證

  The countermeasure against this attack(選擇明文***) is for clients to be configured to require the use of the optional "cnonce" directive;this allows the client to vary the input to the hash in a way not chosen by the attacker.

   

• nc：當服務端開啟qop時，客戶端才需要發(fā)送nc(nonce-count)。服務端能夠通過維護nc來檢測用當前nonce標記的請求重放。如果相同的nc出現(xiàn)在用當前nonce標記的兩次請求中，那么這兩次請求即為重復請求。所以對于防止重放***而言，除了nonce之外，nc才是最后的保障。因此服務端除了維護用戶賬號信息之外，還需要維護nonce和nc的關聯(lián)狀態(tài)數(shù)據(jù)

　　下面將就摘要計算方法進行說明： 

1. 算法的一般性表示

   H(data) = MD5(data)
   KD(secret, data) = H(concat(secret, ":", data))

2. 與安全信息相關的數(shù)據(jù)用A1表示，則

   a) 采用MD5算法：
       A1=(user):(realm):(password)
   b) 采用MD5-sess算法：
       A1=H((user):(realm):(password)):nonce:cnonce

3. 與安全信息無關的數(shù)據(jù)用A2表示，則

   a) QoP為auth或未定義：
       A2=(request-method):(uri-directive-value)
   b) QoP為auth-int：
       A2=(request-method):(uri-directive-value):H((entity-body))

4. 摘要值用response表示，則

   

   a) 若qop沒有定義：
       response
       = KD(H(A1),<nonce>:H(A2))
       = H(H(A1),<nonce>:H(A2))
   b) 若qop為auth或auth-int:
       response
       = KD(H(A1),<nonce>:<nc>:<cnonce>:<qop>:H(A2))
       = H(H(A1),<nonce>:<nc>:<cnonce>:<qop>:H(A2))

   

    

三. 安全風險

• 在線字典***(Online dictionary attacks)：***者可以嘗試用包含口令的字典進行模擬計算response，然后與竊聽到的任何nonce / response對進行對比，若結果一致則***成功。為應對針對弱口令的字典***，降低***成功的可能性，可以禁止用戶使用弱口令

• 中間人(Man in the Middle)：在一次中間人***中，一個弱認證方案被添加并提供給客戶端，因此你總是應該從多個備選認證方案中選擇使用最強的那一個；甚至中間人可能以Basic認證替換掉服務端提供的Digest認證，從而竊取到用戶的安全憑證，然后中間人可利用該憑證去響應服務端的Digest認證盤問；***者還可能打著免費緩存代理服務的幌子來招攬輕信者，通過實施中間人***，盜取他們的安全憑證；中間代理也可能誘導客戶端來發(fā)送一個請求給服務端。為此，客戶端可考慮給出安全等級風險警示，或在跟蹤服務端的認證配置時發(fā)現(xiàn)其認證強度降低就發(fā)出警告，或配置成只使用強認證，或從指定站點來完成認證

• 預先計算字典***(Precomputed dictionary attacks)：***者先構建(response, password) 對字典，然后用選擇性明文(nonce)***的辦法來獲得相應盤問的response，檢索字典找到匹配的response則***成功

• 批量式暴力***(Batch brute force attacks)：中間人會對多個用戶執(zhí)行選擇性明文***來搜集相應的responses，通過控制搜集的nonce / response對的數(shù)量將會縮短找到第一個password的耗時，這種***的應對之策就是要求客戶端使用cnonce指令

• 假冒服務器欺騙(Spoofing by Counterfeit Servers)：對于Basic認證，這種***方式更容易奏效，對于Digest認證則更難，但前提是客戶端必須知道將要使用的是Digest認證。用戶在所使用的認證機制中如何發(fā)現(xiàn)這一潛在***樣式應該得到可見的幫助