摘要訪問認(rèn)證是一種協(xié)議規(guī)定的Web伺服器用來同網(wǎng)頁瀏覽器進(jìn)行認(rèn)證信息協(xié)商的方法。它在密碼發(fā)出前，先對其應(yīng)用哈希函數(shù)，這相對於HTTP基本認(rèn)證發(fā)送明文而言，更安全。

從技術(shù)上講，摘要認(rèn)證是使用隨機(jī)數(shù)來阻止進(jìn)行密碼分析的MD5加密哈希函數(shù)應(yīng)用。它使用HTTP協(xié)議。

概述[編輯]

摘要訪問認(rèn)證最初由 RFC 2069 (HTTP的一個(gè)擴(kuò)展：摘要訪問認(rèn)證)中被定義。RFC 2069 大致定義了一個(gè)傳統(tǒng)的由伺服器生成隨機(jī)數(shù)來維護(hù)安全性的摘要認(rèn)證架構(gòu)。認(rèn)證響應(yīng)由下列組成（HA1、HA2、A1、及A2為字元串變數(shù)的名稱）：

RFC 2069 隨後被 RFC 2617 (HTTP 認(rèn)證：基本及摘要訪問認(rèn)證)。RFC 2617 引入了一系列安全增強(qiáng)的選項(xiàng)；「保護(hù)質(zhì)量」(qop)、隨機(jī)數(shù)計(jì)數(shù)器由客戶端增加、以及客戶生成的隨機(jī)數(shù)。這些增強(qiáng)為了防止如選擇明文攻擊的密碼分析。

如果 qop 值為「auth」或未指定，那麼 HA2 為

如果 qop 值為「auth-int」，那麼 HA2 為

如果 qop 值為「auth」或「auth-int」，那麼如下計(jì)算 response：

如果 qop 未指定，那麼如下計(jì)算 response：

上面所述的這種當(dāng) qop 未指定的情況，也就是遵循簡化的 RFC 2069 標(biāo)準(zhǔn)。

MD5 安全問題對摘要認(rèn)證的影響[編輯]

在 HTTP 摘要認(rèn)證中使用 MD5 加密是為了達(dá)成"不可逆的"，也就是說，當(dāng)輸出已知的時(shí)候，確定原始的輸入應(yīng)該是相當(dāng)困難的。如果密碼本身太過簡單，也許可以通過嘗試所有可能的輸入來找到對應(yīng)的輸出（窮舉攻擊），甚至可以通過字典或者適當(dāng)?shù)牟檎冶砑涌觳檎宜俣取?/p>

HTTP 構(gòu)架由Phillip Hallam-Baker於1993年在CERN設(shè)計(jì)成的，並且沒有吸收後續(xù)認(rèn)證系統(tǒng)的改進(jìn)，如基於密鑰的哈希消息認(rèn)證代碼HMAC的發(fā)展。雖然所使用的密碼結(jié)構(gòu)是基於MD5哈希函數(shù)的，在2004年，通常認(rèn)為衝突攻擊不會影響明文（如密碼）未被得知的應(yīng)用。^{[1][來源請求]} 但是，在2006年的聲明 (Kim, Biryukov2, Preneel, Hong, "On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1") 導(dǎo)致了一些包括關(guān)於 MD5 應(yīng)用的疑慮。不過，至今為止，MD5 衝突攻擊沒有被視為對摘要認(rèn)證的威脅，並且 RFC 2617 允許伺服器實(shí)現(xiàn)一些機(jī)制來檢測衝突以及重放攻擊。

HTTP摘要認(rèn)證的考慮[編輯]

優(yōu)勢[編輯]

HTTP摘要認(rèn)證目的在於比傳統(tǒng)摘要認(rèn)證構(gòu)架更安全；例如，「明顯強(qiáng)於（如）CRAM-MD5……」。 （RFC 2617）

一些HTTP摘要認(rèn)證的安全性增強(qiáng)如下：

• 密碼並非直接在摘要中使用，而是 HA1 = MD5(username:realm:password)。這就允許一些實(shí)現(xiàn)（如，JBoss DIGESTAuth)僅存儲 HA1 而不是明文密碼。
• 在 RFC 2617 中引入了客戶端隨機(jī)數(shù) nonce，這將使客戶端能夠防止選擇明文攻擊（否則，像Rainbow table這類東西就會成為摘要認(rèn)證構(gòu)架的威脅）。
• 伺服器隨機(jī)數(shù) nonce 允許包含時(shí)間戳。因此伺服器可以檢查客戶端提交的隨機(jī)數(shù) nonce，以防止重放攻擊。
• 伺服器也可以維護(hù)一個(gè)最近發(fā)出或使用過的伺服器隨機(jī)數(shù)nonce的列表以防止重用。

劣勢[編輯]

摘要訪問認(rèn)證有意成為一個(gè)安全性的折衷。它意圖代替非加密的HTTP基本認(rèn)證。但是，它沒有被設(shè)計(jì)為替換強(qiáng)認(rèn)證協(xié)議，例如公鑰密碼學(xué)或Kerberos認(rèn)證。

在安全性方面，摘要訪問認(rèn)證有幾個(gè)缺點(diǎn)：

• RFC 2617 中的許多安全選項(xiàng)都是可選的。如果伺服器沒有指定保護(hù)質(zhì)量(qop)，客戶端將以降低安全性的早期的 RFC 2069 的模式操作。
• 摘要訪問認(rèn)證容易受到中間人攻擊。舉例而言，一個(gè)中間人攻擊者可以告知客戶端使用基本訪問認(rèn)證或早期的RFC 2069摘要訪問認(rèn)證模式。進(jìn)一步而言，摘要訪問認(rèn)證沒有提供任何機(jī)制幫助客戶端驗(yàn)證伺服器的身份。
• 一些伺服器要求密碼以可逆加密演算法存儲。但是，僅存儲用戶名、realm、和密碼的摘要是可能的。^[2]
• 它阻止了使用強(qiáng)密碼哈希函數(shù)（如bcrypt）保存密碼（因?yàn)闊o論是密碼、或者用戶名、realm、密碼的摘要都要求是可恢復(fù)的）。

可替代的認(rèn)證協(xié)議[編輯]

一些可以用於Web應(yīng)用程序的強(qiáng)認(rèn)證協(xié)議包括：

• 公鑰密碼學(xué)認(rèn)證（通常隨 HTTPS / SSL客戶端整數(shù)一起實(shí)現(xiàn)）。
• Kerberos或SPNEGO認(rèn)證，主要是在配置為Integrated Windows Authentication (IWA)的微軟的IIS使用。
• Secure Remote Password protocol (適用於HTTPS / TLS層)。

常用的弱明文協(xié)議：

• HTTP基本認(rèn)證構(gòu)架
• HTTP+HTML表單認(rèn)證

使用HTTPS網(wǎng)路加密同時(shí)使用這些弱明文協(xié)議解決了許多摘要訪問認(rèn)證試圖要防止的許多威脅。

示例及說明[編輯]

下面的例子出自 RFC 2617，在這裡進(jìn)行了擴(kuò)展，對每一個(gè)請求和響應(yīng)顯示出完整的文本。注意，這裡僅僅涵蓋了「auth」保護(hù)質(zhì)量的代碼，因?yàn)樵谧珜懫陂g，所知道的只有Opera和Konqueror網(wǎng)頁瀏覽器支持「auth-int」（帶完整性保護(hù)的認(rèn)證）。雖然定義中提到了HTTP 1.1，但是該構(gòu)架可以像下面所描述的這樣添加到1.0的伺服器中去。

典型的認(rèn)證過程包括如下步驟。

• 客戶端請求一個(gè)需要認(rèn)證的頁面，但是不提供用戶名和密碼。通常這是由於用戶簡單的輸入了一個(gè)地址或者在頁面中點(diǎn)擊了某個(gè)超連結(jié)。
• 伺服器返回401 "Unauthorized" 響應(yīng)代碼，並提供認(rèn)證域(realm)，以及一個(gè)隨機(jī)生成的、只使用一次的數(shù)值，稱為密碼隨機(jī)數(shù) nonce。
• 此時(shí)，瀏覽器會向用戶提示認(rèn)證域(realm)（通常是所訪問的計(jì)算機(jī)或系統(tǒng)的描述），並且提示用戶名和密碼。用戶此時(shí)可以選擇取消。
• 一旦提供了用戶名和密碼，客戶端會重新發(fā)送同樣的請求，但是添加了一個(gè)認(rèn)證頭包括了響應(yīng)代碼。
• 在這個(gè)例子中，伺服器接受了認(rèn)證並且返回了請求頁面。如果用戶名非法和/或密碼不正確，伺服器將返回"401"響應(yīng)代碼，然後客戶端會再次提示用戶輸入用戶名及密碼。

注意：客戶端可能已經(jīng)擁有了用戶名和密碼，因此不需要提示用戶，比如以前存儲在瀏覽器里的。

客戶端請求 (無認(rèn)證)

GET /dir/index.html HTTP/1.0 Host: localhost 

(跟隨一個(gè)新行，形式為一個(gè)回車再跟一個(gè)換行） ^[3]

伺服器響應(yīng)

HTTP/1.0 401 Unauthorized Server: HTTPd/0.9 Date: Sun, 10 Apr 2005 20:26:47 GMT WWW-Authenticate: Digest realm="testrealm@host.com",                         qop="auth,auth-int",                         nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",                         opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: text/html Content-Length: 311  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML>   <HEAD>     <TITLE>Error</TITLE>     <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">   </HEAD>   <BODY><H1>401 Unauthorized.</H1></BODY> </HTML> 

客戶端請求 (用戶名 "Mufasa", 密碼 "Circle Of Life")

GET /dir/index.html HTTP/1.0 Host: localhost Authorization: Digest username="Mufasa",                      realm="testrealm@host.com",                      nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",                      uri="/dir/index.html",                      qop=auth,                      nc=00000001,                      cnonce="0a4f113b",                      response="6629fae49393a05397450978507c4ef1",                      opaque="5ccc069c403ebaf9f0171e9517f40e41" 

(跟隨一個(gè)新行，形式如前所述).

伺服器響應(yīng)

HTTP/1.0 200 OK Server: HTTPd/0.9 Date: Sun, 10 Apr 2005 20:27:03 GMT Content-Type: text/html Content-Length: 7984 

(隨後是一個(gè)空行，然後是所請求受限制的HTML頁面).

如下所述，response 值由三步計(jì)算而成。當(dāng)多個(gè)數(shù)值合併的時(shí)候，使用冒號作為分割符。

1. 對用戶名、認(rèn)證域(realm)以及密碼的合併值計(jì)算 MD5 哈希值，結(jié)果稱為 HA1。
2. 對HTTP方法以及URI的摘要的合併值計(jì)算 MD5 哈希值，例如，"GET" 和 "/dir/index.html"，結(jié)果稱為 HA2。
3. 對 HA1、伺服器密碼隨機(jī)數(shù)(nonce)、請求計(jì)數(shù)(nc)、客戶端密碼隨機(jī)數(shù)(cnonce)、保護(hù)質(zhì)量(qop)以及 HA2 的合併值計(jì)算 MD5 哈希值。結(jié)果即為客戶端提供的 response 值。

因?yàn)樗欧鲹碛信c客戶端同樣的信息，因此伺服器可以進(jìn)行同樣的計(jì)算，以驗(yàn)證客戶端提交的 response 值的正確性。在上面給出的例子中，結(jié)果是如下計(jì)算的。 （MD5()表示用於計(jì)算 MD5 哈希值的函數(shù)；「\」表示接下一行；引號並不參與計(jì)算）

完成 RFC 2617 中所給出的示例，將在每步得出如下結(jié)果。

   HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )        = 939e7578ed9e3c518a452acee763bce9     HA2 = MD5( "GET:/dir/index.html" )        = 39aff3a2bab6126f332b942af96d3366     Response = MD5( "939e7578ed9e3c518a452acee763bce9:\                     dcd98b7102dd2f0e8b11d0f600bfb0c093:\                     00000001:0a4f113b:auth:\                     39aff3a2bab6126f332b942af96d3366" )             = 6629fae49393a05397450978507c4ef1 

此時(shí)客戶端可以提交一個(gè)新的請求，重複使用伺服器密碼隨機(jī)數(shù)(nonce)（伺服器僅在每次「401」響應(yīng)後發(fā)行新的nonce），但是提供新的客戶端密碼隨機(jī)數(shù)(cnonce)。在後續(xù)的請求中，十六進(jìn)制請求計(jì)數(shù)器(nc)必須比前一次使用的時(shí)候要大，否則攻擊者可以簡單的使用同樣的認(rèn)證信息重放老的請求。由伺服器來確保在每個(gè)發(fā)出的密碼隨機(jī)數(shù)nonce時(shí)，計(jì)數(shù)器是在增加的，並拒絕掉任何錯(cuò)誤的請求。顯然，改變HTTP方法和/或計(jì)數(shù)器數(shù)值都會導(dǎo)致不同的 response 值。

伺服器應(yīng)當(dāng)記住最近所生成的伺服器密碼隨機(jī)數(shù)nonce的值。也可以在發(fā)行每一個(gè)密碼隨機(jī)數(shù)nonce後，記住過一段時(shí)間讓它們過期。如果客戶端使用了一個(gè)過期的值，伺服器應(yīng)該響應(yīng)「401」?fàn)顟B(tài)號，並且在認(rèn)證頭中添加stale=TRUE，表明客戶端應(yīng)當(dāng)使用新提供的伺服器密碼隨機(jī)數(shù)nonce重發(fā)請求，而不必提示用戶其它用戶名和口令。

伺服器不需要保存任何過期的密碼隨機(jī)數(shù)，它可以簡單的認(rèn)為所有不認(rèn)識的數(shù)值都是過期的。伺服器也可以只允許每一個(gè)伺服器密碼隨機(jī)數(shù)nonce使用一次，當(dāng)然，這樣就會迫使客戶端在發(fā)送每個(gè)請求的時(shí)候重複認(rèn)證過程。需要注意的是，在生成後立刻過期伺服器密碼隨機(jī)數(shù)nonce是不行的，因?yàn)榭蛻舳藢]有任何機(jī)會來使用這個(gè)nonce。

SIP 摘要認(rèn)證[編輯]

SIP基本上使用了同樣的摘要認(rèn)證演算法。它由 RFC 3261 定義。

瀏覽器實(shí)現(xiàn)[編輯]

大多數(shù)瀏覽器都基本上實(shí)現(xiàn)了該協(xié)議，除了某些特性，比如檢查auth-int、或者M(jìn)D5-sess演算法。如果伺服器要求處理這類可選特性，客戶端可能無法進(jìn)行認(rèn)證（雖然需要注意的是，Apache伺服器的mod_auth_digest模塊也沒有完全實(shí)現(xiàn) RFC 2617）。

• Amaya
• 基於Gecko: (不包括 auth-int: [1])
  • Mozilla Application Suite
  • Mozilla Firefox
  • Netscape 7+
• iCab 3.0.3+
• 基於KHTML- 及 WebKit: (不包括 auth-int [2])
  • iCab 4
  • Konqueror
  • Google Chrome
  • Safari
• 基於Tasman:
  • Internet Explorer for Mac
• Trident-based:
  • Internet Explorer 7+ ^[4] (不包括 auth-int)
• 基於Presto:
  • Opera
  • Opera Mobile
  • Opera Mini
  • Nintendo DS 瀏覽器
  • Nokia 770 瀏覽器
  • Sony Mylo 1 的瀏覽器
  • Wii Internet Channel 瀏覽器

參見[編輯]

• 認(rèn)證和密鑰協(xié)商協(xié)議
• HTTP基本認(rèn)證

參考[編輯]

外部連結(jié)[編輯]

• RFC 2617
• RFC 2069 (廢棄的)