HTTP之基本認證

認證

　　認證就是要給出一些×××明。當出示像護照或駕照那樣有照片的×××件時，就給出了一些證據，說明你就是你所聲稱的那個人。在自動取款機上輸入PIN碼，或在計算機系統的對話框中輸入密碼時，也是在證明你就是你所聲稱的那個人

　　現在，這些策略都不是絕對有效的。密碼可以被猜出來或被人偶然聽到，×××件可能被偷去或被偽造，但每種證據都有助于構建合理的信任，說明你就是你所聲稱的那個人

【HTTP的質詢/響應認證框架】

　　HTTP提供了一個原生的質詢/響應(challenge/response)框架，簡化了對用戶的認證過程。HTTP的認證模型如下圖所示

　　Web應用程序收到一條HTTP請求報文時，服務器沒有按照請求執行動作，而是以一個“認證質詢”進行響應，要求用戶提供一些保密信息來說明他是誰，從而對其進行質詢

　　用戶再次發起請求時，要附上保密證書(用戶名和密碼)。如果證書不匹配，服務器可以再次質詢客戶端，或產生一條錯誤信息。如果證書匹配，就可以正常完成請求了

【認證協議與首部】

　　HTTP通過一組可定制的控制首部，為不同的認證協議提供了一個可擴展框架。下表列出的首部格式和內容會隨認證協議的不同而發生變化。認證協議也是在HTTP認證首部中指定的

　　HTTP定義了兩個官方的認證協議：基本認證和摘要認證。今后人們可以隨意設計一些使用HTTP質詢/響應框架的新協議

　　關于基本認證的實例，如下圖所示

　　服務器對用戶進行質詢時，會返回一條401 Unauthorized響應，并在WWW-Authenticate首部說明如何以及在哪里進行認證

　　當客戶端授權服務器繼續處理時，會重新發送請求，但會在Authorization首部附上加密的密碼和其他一些認證參數

　　授權請求成功完成時，服務器會返回一個正常的狀態碼(比如，200 OK)，對髙級認證算法來說，可能還會在Authentication-Info首部附加一些額外的信息

【安全域】

　　在對基本認證的細節進行討論之前，需要解釋一下HTTP是怎樣允許服務器為不同的資源使用不同的訪問權限的。上圖(b)的WWW-Authenticate質詢中包含了一個realm指令。Web服務器會將受保護的文檔組織成一個安全域(security realm)。每個安全域都可以有不同的授權用戶集

　　比如，假設Web服務器建立了兩個安全域：一個用于公司的財務信息，另一個用于個人家庭文檔。不同的用戶對各個安全域的訪問權限是不同的。公司的CEO應該能夠訪問銷售額預測資料，但不應該允許他訪問員工和其家人度假的照片

　　下面是一個假想的基本認證質詢，它指定了一個域:

HTTP/1.0 401 Unauthorized
WWW-Authenticate： Basic realm="Corporate Financials"

　　域應該有一個描述性的字符名，比如Corporate Financials(公司財務資料)，以幫助用戶了解應該使用哪個用戶名和密碼。在安全域的名稱中列出服務器主機名也是很有幫助的——比如，executive-committee@bigcompany.com

基本認證

　　基本認證是最流行的HTTP認證協議。幾乎每個主要的客戶端和服務器都實現了基本認證機制。基本認證最初是在HTTP/1.0規范中提出的，但此后被移到了RFC 2617中，它詳細介紹了HTTP的認證機制

　　在基本認證中，Web服務器可以拒絕一個事務，質詢客戶端，請用戶提供有效的用戶名和密碼。服務器會返回401狀態碼，而不是200狀態碼來初始化認證質詢，并用WWW-Authenticate響應首部指定要訪問的安全域。瀏覽器收到質詢時，會打開一個對話框，請求用戶輸入這個域的用戶名和密碼。然后將用戶名和密碼稍加擾碼，再用Authorization請求首部回送給服務器

【基本認證實例】

　　下圖是一個詳細的基本認證實例

　　在圖a中，用戶請求了私人家庭相片/family/jeff.jpg

　　在圖b中，服務器回送一條401 Authorization Required，對私人家庭相片進行密碼質詢，同時回送的還有WWW-Authenticate首部。這個首部請求對Family域進行基本認證

　　在圖c中，瀏覽器收到了401質詢，彈出對話框，詢問Family域的用戶名和密碼。用戶輸入用戶名和密碼時，瀏覽器會用一個冒號將其連接起來，編碼成“經過擾碼的”Base-64表示形式，然后將其放在Authorization首部中回送

　　在圖d中，服務器對用戶名和密碼進行解碼，驗證其正確性，然后用一條HTTP 200 0K報文返回所請求的報文

　　下表總結了HTTP基本認證的WWW-Authenticate和Authorization首部

　　[注意]基本認證協議并沒有使用Authentication-Info首部

【Base-64用戶名/密碼編碼】

　　HTTP基本認證將(由冒號分隔的)用戶名和密碼打包在一起，并用Base-64編碼方式對其進行編碼。簡單來說，Base-64編碼會將一個8位字節序列劃分為一些6位的塊。用每個6位的塊在一個特殊的由64個字符組成的字母表中選擇一個字符，這個字母表中包含了大部分字母和數字

　　下圖顯示了使用Base-64編碼的基本認證實例。在這個例子中，用戶名為brian-totty，密碼為Ow!。瀏覽器用冒號將用戶名和密碼連接起來，生成一個打包字符串brian-totty:Ow!。然后對這個字符串進行Base-64編碼，變成一串亂碼：YnJpYW4tdG90dHk6T3ch

　　Base-64編碼可以接受二進制字符串、文本、國際字符表示的數據(在某些系統中 會引發一些問題)，將其暫時轉換成一個易移植的字母表以便傳輸。然后，在遠端就可以解碼出原始字符串，而無需報心傳輸錯誤了

　　有些用戶名和密碼中會包含國際字符或其他在HTTP首部中非法的字符(比如引號、冒號和回車換行符)，對這些用戶名和密碼來說，Base-64編碼是非常有用的。而且，Base-64編碼擾亂了用戶名和密碼，這樣也可以防止管理員在管理服務器和網絡時，不小心看到用戶名和密碼

【代理認證】

　　中間的代理服務器也可以實現認證功能。有些組織會在用戶訪問服務器、LAN或無線網絡之前，用代理服務器對其進行認證。可以在代理服務器上對訪問策略進行集中管理。因此，通過代理服務器提供對某組織內部資源的統一訪問控制是一種很便捷的方式。這個過程的第一步就是通過代理認證(proxy authentication)來識別身份

　　代理認證的步驟與Web服務器身份驗證的步驟相同。但首部和狀態碼都有所不同。 下表列出了Web服務器和代理在認證中使用的狀態碼和首部的差異

安全缺陷

　　基本認證簡單便捷，但并不安全。只能用它來防止非惡意用戶無意間進行的訪問，或將其與SSL這樣的加密技術配合使用

　　基本認證會通過網絡發送用戶名和密碼，這些用戶名和密碼都是以一種很容易解碼的形式表示的。實際上，密碼是以明文形式傳輸的，任何人都可以讀取并將其捕獲。雖然Base-64編碼通過隱藏用戶名和密碼，致使友好的用戶不太可能在進行網絡觀測時無意中看到密碼，但Base-64編碼的用戶名和密碼可以很輕易地通過反向編碼過程進行解碼，甚至可以用紙筆在幾秒鐘內手工對其進行解碼，所以經過Base-64編碼的密碼實際上就是“明文”傳送的。如果有動機的第三方用戶有可能會去攔截基本認證發送的用戶名和密碼，就要通過SSL加密信道發送所有的HTTP事務，或者使用更安全的認證協議，比如摘要認證

　　即使密碼是以更難解碼的方式加密的，第三方用戶仍然可以捕獲被修改過的用戶名和密碼，并將修改過的用戶名和密碼一次一次地重放給原始服務器，以獲得對服務器的訪問權。沒有什么措施可用來防止這些重放***

　　即使將基本認證用于一些不太重要的應用程序，比如公司內部網絡的訪問控制或個性化內容的訪問，一些不良習慣也會讓它變得很危險。很多用戶由于受不了大量密碼保護的服務，會在這些服務間使用相同的用戶名和密碼。比如說，***會從免費的因特網郵件網站捕獲明文形式的用戶名和密碼，然后會發現用同樣的用戶名和密碼還可以訪問重要的在線銀行網站

　　基本認證沒有提供任何針對代理和作為中間人的中間節點的防護措施，它們沒有修改認證首部，但卻修改了報文的其余部分，這樣就嚴重地改變了事務的本質

　　假冒服務器很容易騙過基本認證。如果在用戶實際連接到一臺惡意服務器或網關的時候，能夠讓用戶相信他連接的是一個受基本認證保護的合法主機，***者就可以請求用戶輸入密碼，將其存儲起來以備未來使用，然后捏造一條錯誤信息傳送給用戶

　　這一切說明，在友好的環境，或者說是希望有隱私保護但隱私保護并不十分必要的環境中，可以通過基本認證來提供便捷的文檔個性化服務或訪問控制保護。通過這種方式，可以用基本認證來防止一些好奇的用戶無意中或不小心對文檔進行訪問

　　比如，在一個公司內部，產品管理可能要對未來的產品計劃進行密碼保護，以防止信息的過早發布。對一般用戶而言，基本認證就足以讓他們感到不便而不會再去訪問這些數據了。同樣，可能會用密碼來保護那些并非高度機密的，或者沒什么信息價值的私人照片或私有站點，這些信息確實和其他人也沒什么關系

　　將基本認證與加密數據傳輸(比如SSL)配合使用，向惡意用戶隱藏用戶名和密碼，會使基本認證變得更加安全。這是一種常用的技巧