HTTP——學習筆記（7）

HTTP中的認證機制

 

什麼是認證機制？：

服務器須要知道客戶端是誰。

 

怎樣知道客戶端身份？：

覈對「登陸者本人才知道的信息」

　　密碼：只有本人才會知道的字符串信息

　　動態令牌：僅限本人持有的設備內顯示的一次性密碼

　　數字證書：僅限本人（終端）持有的信息

　　生物證書：指紋和虹膜等本人的生理信息

　　IC卡等：僅限本人持有的信息

 

HTTP/1.1使用的認證方式有哪些？：

BASIC認證（基本認證）

DIGEST認證（摘要認證）

SSL客戶端認證

FormBase認證（基於表單認證）

此外，還有Windows統一認證（Keberos認證，NTLM認證）

 

BASIC認證步驟：

1.當請求的資源須要BASIC認證時，服務器會隨狀態碼401 Authorization Required，返回帶WWW-Authenticate首部字段的響應。該字段內包含認證的方式（BASIC）及Request-URI安全域字符串

2.接受到狀態碼401的客戶端爲了經過BASIC認證，須要將用戶ID及密碼發送給服務器。發送的字符串內容是由用戶ID和密碼構成，二者中間以冒號鏈接後，再通過Base64編碼處理。當用戶代理爲瀏覽器時，用戶僅需輸入用戶ID和密碼便可，以後，瀏覽器會自動完成到Base64編碼的轉換工做

3.接收到包含首部字段Authorization請求的服務器，會對認證信息的正確性進行驗證。如驗證經過，則返回一條包含Request-URI資源的響應。

BASIC認證缺點：

　　1.雖然採用了Base64編碼方式，可是並非加密處理，信息仍有被竊聽的危險

　　2.除此以外想再進行一次BASIC認證時，通常的瀏覽器卻沒法實現認證註銷操做

BASIC不夠靈活，不經常使用

 

DIGEST認證步驟：

1.請求需認證的資源時，服務器會隨着狀態碼401 Authorization Required,返回帶WWW-Authenticate首部字段的響應。該字段內包含質問響應方式認證所需的臨時質詢碼（隨機數，nonce）和realm字段信息

2.接受到401狀態碼的客戶端，返回的響應中包含DIGEST認證必須的首部字段信息Authorization

信息。首部字段Authorization內必須包含username,realm,nonce,uri和response的字段信息。其中，realm和nonce就是以前從服務器接受到的響應中的字段

3.接受到包含首部字段Authorization請求的服務器，會確認認證信息的正確性。認證經過後則返回包含Request-URI資源的響應，而且這時會在首部字段Authorization-Info寫入一些認證成功的相關信息

缺點：　　

　　使用上不便捷靈活，而且仍然達不到多數WEB網站對高度安全等級的追求標準。

 

SSL客戶端認證步驟：

1.接收到須要認證資源的請求，服務器會發送Certificate Request報文，要求客戶端提供客戶端證書（須要時先將客戶端證書分發給客戶端，且客戶端必須安裝此證書）

2.用戶選擇將發送的客戶端證書後，客戶端會把客戶端證書信息以Client Certificate報文方式發送給服務器

3.服務器驗證客戶端證書驗證經過後方可領取證書內客戶端的公開密鑰，而後開始HTTPS加密通訊

缺點：

　　須要支付高額的費用

 

基於表單驗證：

輸入已事先登陸的用戶ID，和密碼等登陸信息後，發送給WEB應用程序，基於認證結果來決定認證是否成功

步驟：

1.客戶端把用戶ID和密碼等登陸信息放入報文的實體部分，一般是以POST方法把請求發送給服務器。而這時，會使用HTTPS通訊來進行HTML表單畫面的顯示和用戶輸入數據的發送。

2.服務器會發放用以識別用戶的Session ID。經過驗證從客戶端發送過來的登陸信息進行身份認證，而後把用戶的認證狀態與Session ID綁定後記錄在服務器端（在首部字段Set-Cookie內寫入Session ID）

3.客戶端接收到從服務器端發來的Session ID後，會將其做爲Cookie保存在本地。下次向服務器發送請求時，瀏覽器會自動發送Cookie，因此Session ID也隨之發送到服務器。服務器端可經過驗證接收到的Session ID識別用戶和其認證狀態

注：密碼加鹽：一種服務器端保存用戶密碼加密方式，由服務器隨機生成一個字符串，保證長度足夠長，而且是真正隨機生成的。而後把它和密碼字符串相鏈接（先後均可以）生成散列值。當兩個用戶使用了用一個密碼時，因爲隨機生成的salt值不一樣，對應的散列值也將是不一樣的。這樣一來，很大程度上減小了密碼特徵，攻擊者也就很難利用本身手中的密碼特徵庫進行破解。