HTTP認證模式 (2015-05-05 09:29:47)
轉載
▼
分類： Windows編程
http://www.adeploy.com/2012/08/17/http-auth-schemes/#more-93008
前言
最近在研究curl和httpclient，用到了HTTP認證相關的知識。
但是搜索之後發現，網上居然沒有很全面的HTTP認證模式的介紹，尤其是中文的文章。
因此結合MS的Understanding HTTP Authentication和HttpClient Tutorial翻譯加個人理解寫了一篇。
一、簡介
本篇博文簡介了幾種HTTP認證模式。文章內容要求讀者對HTTP請求、響應的基本結構，HTTP狀態碼和HTTP協議頭有一定的瞭解。
請參考Linux下cURL使用教程之二：HTTP協議概述。
二、HTTP訪問認證框架
HTTP協議（RFC2616）定義了一個簡單的訪問認證模式框架。此框架假設有若干頁面（被保護資源，也稱作realm，區域），只能被特定的人訪問，這些人可以在服務器要求時提供憑證。
當客戶端如瀏覽器訪問一個位於保護區域（protected realm）中的頁面時，服務器返回包含401未認證狀態碼和www認證頭（WWW-Authenticate header
field）的響應。返回的認證頭中必須含有至少一個適用於請求頁面的認證要求（challenge）。
然後客戶端發起第二次請求，此次請求在請求頭中包含了試用於服務器認證要求的認證頭域。
如果服務器接受了客戶端提供的憑證，它將返回客戶端請求的頁面。否則，服務端會返回另一個401未認證響應以提示客戶端認證失敗。
具體認證響應頭和請求頭的內容取決於認證的方式。RFC2616中定義了兩種廣泛使用的認證模式：
HTTP基本認證（HTTP Basic authentication）和HTTP摘要認證（HTTP Digest authentication）。
此外常用的還有NTLM、SPNEGO（HTTP協商認證，HTTP Negotiate authentication，是其一種）和Kerberos認證方式。
三、認證模式
1、基本認證Basic Access Authentication
基本認證是基於用戶名密碼的。
服務端的401響應中包含一個認證要求（authentication challenge），此認證要求中含有“Basic”關鍵字和一個用以表明訪問的被保護資源名稱的“名稱=值”對，如下：
WWW-Authenticate: Basic realm=”Protected page”
如果你使用的瀏覽器，瀏覽器在接收到401響應時，將會彈出窗口讓你輸入用戶名密碼，然後發送認證請求。認證請求中同樣包含”Basic”關鍵字，此外還有Base64編碼後的用戶名密碼，如下：
Authorization: Basic QWRlcGxveSdzIGJsb2c=
服務器將用戶名密碼解碼後比對，成功匹配後即認證成功。
因爲Base64不算是一種加密方法：無密鑰的可逆加密，任何人都可解密（百度搜索一下”在線解碼“一大堆）。因此基本認證被認爲是明文傳輸，安全性不好。極易出現密碼被竊聽和重放攻擊等安全性問題。
如果資源需要更高強度的保護，請使用其他認證方法。
2、摘要認證HTTP Digest authentication
摘要認證被設計用來彌補基本認證的缺點。摘要認證基於請求-響應（challenge-response）模式，而且使用了哈希加密算法（常用爲MD5），從而某些程度上解決了基本認證安全性的問題。
服務器返回的初始401響應的www認證頭（WWW-Authenticate header）中多出了一個稱爲nonce的隨機數的字段。服務端保證每個401響應中的nonce值唯一。如：
Authorization: Digest username=”admin”, realm=”HiPER”
接下來的客戶端響應中將包含由用戶名、密碼、nonce和其他信息組成的數據的哈希值（如使用MD5加密）。所有被加密的數據服務端也具有，因此服務端執行同樣加密過程。如果二者一直則認證成功。
因爲如MD5等哈希加密算法是不可逆的，因此用戶名密碼明文無法被竊聽破解。因爲服務器對同一個nonce的請求只接受一次客戶端請求，從而能避免重放攻擊。
但是，digest的安全性也有缺點：
1）只有密碼密碼被加密，而客戶端最終請求的被保護資源是明文傳送的，可被竊聽
2）客戶端無法確認服務端的正確身份，缺少對服務端的認證方式
3）近年來，隨着計算機性能的提高等因素，傳統高強度加密算法的破解已成可能。而MD5更是已有破解方法。
更多安全性問題請參考RFC2617。
3、NTML
NTML由微軟開發，使用於Windows平臺。被認爲是比摘要認證更安全的認證方式。
它使用Windows憑證（Windows credentials）來傳遞認證數據，而不是使用未編碼的用戶名密碼。
NTML要求服務器與客戶端做出多次數據交換，服務器和所有其中的代理都必須支持永久連接（persistent connections）才能完成認證。
4、Kerberos
服務器與客戶端通過第三方的Kerberos服務器完成認證。具體請參見百度百科條目和維基百科條目。
Kerberose相比NTML有很大改善：速度快，而且允許相互認證、認證代理和簡單的信任關係。參考KERBEROS vs NTLM。
5、SPNEGO
全稱是Simple and Protected GSS-API Negotiation，是微軟提供的一種使用GSS-API認證機制的安全協議，用於使Webserver共享Windows Credentials，它擴展了Kerberos(一種網絡認證協議)。
SPNEGO適用於客戶端需要認證，但是客戶端服務端都不清楚對方支持什麼認證協議的場合。
SPENGO其實是一種”僞認證機制“（pseudo-mechanism），用以協商出真正的認證機制。
最常見的是微軟的HTTP協商認證擴展（HTTP Negotiate authentication extension），協商的最終機制在NTML和Kerberos中選擇。Kerberos因其優點優先使用。
百度詞條對此認證的解釋是不夠準確的，準確的解釋可以參考維基百科條目。
四、認證方式選擇
選擇何種認證方式取決於資源要被保護的程度。不需要保護的資源使用基本認證方式。因爲認證會導致更多的數據傳輸，可能影響用戶體驗。
認證方式最弱的是基本認證，最強的是協商認證。服務端在WWW-Authentication提供自己支持的認證方式，供客戶端任意選擇。
五、參考
RFC2616-HTTP協議
RFC2617-HTTP認證：基本認證和摘要認證
RFC1321-MD5摘要加密邏輯