Basic認證實際上是明文傳遞密碼，所以RFC2617裏定義了Digest認證以取代它，其計算方法如下：
其中HA1計算方法爲：
如果qop選項的值爲auth，那麼HA2散列計算方法爲：
如果qop選項的值爲auth-int，那麼HA2散列計算方法爲：
密碼的問題：
當客戶端請求到達的時候，服務器程序爲了驗證其response是否合法，必須按照上面的計算方法重新構建response，那麼爲了能算出HA1散列，必須滿足以下兩個條件之一：要麼在數據庫裏保存原始密碼，要麼在數據庫保存事先計算好的HA1。不過這在實際應用中都很難滿足。
實際應用裏，密碼一般都是保存其md5散列，想得周到點的，會加一個salt再md5。首先，保存原始密碼是不可想象的，一旦數據庫出問題，密碼直接處於裸奔狀態，問題就嚴重了。其次，預先保存計算好的HA1也是很難的，除非是新應用，否則老系統估計不太可能會那麼有前瞻性去保存一個HA1。
攻擊的問題：
在Basic認證裏，一旦請求被黑客嗅探到，那麼密碼就暴露了，在Digest認證裏，雖然黑客不可能直接嗅探到密碼，但是他可以利用拿到的請求頭信息構造一個看似合法的請求，或者黑客還可以進行更赤裸裸的暴力破解攻擊。如果想屏蔽這些攻擊，服務器必須記錄哪些nonce已經被用過了。
在一個繁忙的網站裏，如果每次請求的nonce值都要記錄下來的話，那用不了多久，數據量就會達到一個天文數字，這無疑增加了服務器的負擔。相對而言，比較實際的做法是僅僅記錄一段時間內的nonce值，比如一個小時內的nonce值，但黑客同樣也可以一個小時候後再發起攻擊，所以還得把nonce的產生和時間戳結合起來纔行，屏蔽過期的nonce，或者把nonce和ip結合起來，不過問題的解決方案也一點一點變得複雜了。
參考文章
http://en.wikipedia.org/wiki/Digest_access_authentication