TCP/IP基礎總結性學習（8）

確認訪問用戶身份的認證

• 某些 Web 頁面只想讓特定的人瀏覽，或者乾脆僅本人可見。爲達到這個目標，必不可少的就是認證功能。下面咱們一塊兒來學習一下認證機制。

---

一.　何爲認證

1.計算機自己沒法判斷坐在顯示器前的使用者的身份。進一步說，也沒法確認網絡的那頭究竟有誰。可見，爲了弄清到底是誰在訪問服務器，就得讓對方的客戶端自報家門。但是，就算正在訪問服務器的對方聲稱本身是ueno，身份是否屬實這點卻也無從談起。爲確認 ueno 本人是否真的具備訪問系統的權限， 就須要覈對「登陸者本人才知道的信息」、「登陸者本人才會有的信息」。

2.覈對的信息一般是指如下這些:
密碼：只有本人才會知道的字符串信息。
動態令牌：僅限本人持有的設備內顯示的一次性密碼。
數字證書：僅限本人（終端）持有的信息。
生物認證：指紋和虹膜等本人的生理信息。
IC 卡等：僅限本人持有的信息。

可是，即使對方是假冒的用戶，只要能經過用戶驗證，那麼計算機就會默認是出自本人的行爲。所以，掌控機密信息的密碼毫不能讓他人獲得，更不能輕易地就被破解出來。HTTP 使用的認證方式 HTTP/1.1 使用的認證方式以下所示。 BASIC 認證（基本認證） DIGEST 認證（摘要認證）SSL 客戶端認證 FormBase 認證（基於表單認證）此外，還有 Windows 統一認證（Keberos 認證、NTLM 認證）。

---

二.BASIC 認證BASIC

認證（基本認證）是從 HTTP/1.0 就定義的認證方式。即使是如今仍有一部分的網站會使用這種認證方式。是 Web 服務器與通訊客戶端之間進行的認證方式。

1.BASIC 認證的認證步驟

步驟 1： 當請求的資源須要 BASIC 認證時，服務器會隨狀態碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應。 該字段內包含認證的方式（BASIC） 及 Request-URI 安全域字符串 （realm）。
步驟 2： 接收到狀態碼 401 的客戶端爲了經過 BASIC 認證，須要將用戶 ID 及密碼發送給服務器。發送的字符串內容是由用戶 ID 和密碼構成，二者中間以冒號（:）鏈接後，再通過 Base64 編碼處理。

假設用戶 ID 爲 guest，密碼是 guest，鏈接起來就會造成 guest:guest 這樣的字符串。而後通過 Base64 編碼，最後的結果便是 Z3Vlc3Q6Z3Vlc3Q=。把這串字符串寫入首部字段 Authorization 後，發送請求。
當用戶代理爲瀏覽器時，用戶僅需輸入用戶 ID 和密碼便可，以後，瀏覽器會自動完成到 Base64 編碼的轉換工做。

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

BASIC 認證雖然採用 Base64 編碼方式，但這不是加密處理。不須要任何附加信息便可對其解碼。換言之，因爲明文解碼後就是用戶 ID 和密碼，在 HTTP 等非加密通訊的線路上進行 BASIC 認證的過程當中，若是被人竊聽，被盜的可能性極高。另外，除此以外想再進行一次 BASIC 認證時，通常的瀏覽器卻沒法實現認證註銷操做，這也是問題之一。BASIC 認證使用上不夠便捷靈活，且達不到多數 Web 網站指望的安全性等級，所以它並不經常使用。

---

三.　DIGEST 認證

• 爲彌補 BASIC 認證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認證。 DIGEST 認證一樣使用質詢 / 響應的方式 （challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。

1.所謂質詢響應方式是指，一開始一方會先發送認證要求給另外一方，接着使用從另外一方那接收到的質詢碼計算生成響應碼。最後將響應碼返回給對方進行認證的方式。

由於發送給對方的只是響應摘要及由質詢碼產生的計算結果，因此比起 BASIC 認證，密碼泄露的可能性就下降了。

DIGEST 認證的認證步驟:

步驟 1： 請求需認證的資源時，服務器會隨着狀態碼 401 Authorization Required，返 迴帶 WWW-Authenticate 首部字段的響應。該字段內包含質問響應方式認證所需的臨時質詢碼（隨機數，nonce）。首部字段 WWW-Authenticate 內必須包含 realm 和 nonce 這兩個字段的信息。客戶端就是依靠向服務器回送這兩個值進行認證的。nonce 是一種每次隨返回的 401 響應生成的任意隨機字符串。該字符串一般推薦由 Base64 編碼的十六進制數的組成形式，但實際內容 賴服務器的具體實現。

步驟 2： 接收到 401 狀態碼的客戶端，返回的響應中包含 DIGEST 認證必須的首部字段 Authorization 信息。 首部字段 Authorization 內必須包含 username、realm、nonce、uri 和 response 的字段信息。其中，realm 和 nonce 就是以前從服務器接收到 的響應中的字段。username 是 realm 限定範圍內可進行認證的用戶名。 uri（digest-uri）即 Request-URI 的值，但考慮到經代理轉發後 Request-URI 的值可能被修改，所以事先會複製一份副本保存在 uri 內。response 也可叫作 Request-Digest，存放通過 MD5 運算後的密碼字符串，造成響應碼。響應中其餘的實體請參見第 6 章的請求首部字段 Authorization。另外，有關 Request-Digest 的計算規則較複雜，有興趣的讀者不妨深刻 學習一下 RFC2617。

步驟 3： 接收到包含首部字段 Authorization 請求的服務器，會確認認證信息的正確性。認證經過後則返回包含 Request-URI 資源的響應。 而且這時會在首部字段 Authentication-Info 寫入一些認證成功的相關信息。DIGEST 認證提供了高於 BASIC 認證的安全等級，可是和 HTTPS 的客戶端認證相比仍舊很弱。DIGEST 認證提供防止密碼被竊聽的保護機制，但並不存在防止用戶假裝的保護機制。DIGEST 認證和 BASIC 認證同樣，使用上不那麼便捷靈活，且仍達不到多數 Web 網站對高度安全等級的追求標準。所以它的適用範圍也 有所受限。

---

四.SSL 客戶端認證

從使用用戶 ID 和密碼的認證方式方面來說，只要兩者的內容正確， 便可認證是本人的行爲。但若是用戶 ID 和密碼被盜，就頗有可能被第三者冒充。利用 SSL 客戶端認證則能夠避免該狀況的發生。SSL 客戶端認證是藉由 HTTPS 的客戶端證書完成認證的方式。憑藉客戶端證書（在 HTTPS 一章已講解）認證，服務器可確認訪問是否來自已登陸的客戶端。

• SSL 客戶端認證的認證步驟爲達到 SSL 客戶端認證的目的，須要事先將客戶端證書分發給客戶端，且客戶端必須安裝此證書。

步驟 1： 接收到須要認證資源的請求，服務器會發送 Certificate Request 報文，要求客戶端提供客戶端證書。
步驟 2： 用戶選擇將發送的客戶端證書後，客戶端會把客戶端證書信息以 Client Certificate 報文方式發送給服務器。

圖：選擇客戶端證書示例（三菱東京 UFJ 銀行）

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

• SSL 客戶端認證採用雙因素認證在多數狀況下，SSL客戶端認證不會僅依靠證書完成認證，通常會和基於表單認證（稍後講解）組合造成一種雙因素認證（Two-factor authentication）來使用。所謂雙因素認證就是指，認證過程當中不只須要密碼這一個因素，還須要申請認證者提供其餘持有信息，從而做爲另外一個因素，與其組合使用的認證方式。換言之，第一個認證因素的 SSL 客戶端證書用來認證客戶端計算機，另外一個認證因素的密碼則用來肯定這是用戶本人的行爲。經過雙因素認證後，就能夠確認是用戶本人正在使用匹配正確的計算機訪問服務器。
• SSL 客戶端認證必要的費用使用 SSL 客戶端認證須要用到客戶端證書。而客戶端證書須要支付一 定費用才能使用。這裏提到的費用是指，從認證機構購買客戶端證書的費用，以及服務 器運營者爲保證本身搭建的認證機構安全運營所產生的費用。每一個認證機構頒發客戶端證書的費用不盡相同，平攤到一張證書上，一年費用約幾萬至十幾萬日元。服務器運營者也能夠本身搭建認證機構，但要維持安全運行就會產生相應的費用。

---

五.基於表單認證

基於表單的認證方法並非在 HTTP 協議中定義的。客戶端會向服務器上的 Web 應用程序發送登陸信息（Credential），按登陸信息的驗證結果認證。根據 Web 應用程序的實際安裝，提供的用戶界面及認證方式也各不相同。

圖：基於表單認證示例（Google）
多數狀況下，輸入已事先登陸的用戶 ID（一般是任意字符串或郵件 地址）和密碼等登陸信息後，發送給 Web 應用程序，基於認證結果 來決定認證是否成功。

• 認證多半爲基於表單認證

因爲使用上的便利性及安全性問題，HTTP 協議標準提供的 BASIC 認證和 DIGEST 認證幾乎不怎麼使用。另外，SSL 客戶端認證雖然具備高度的安全等級，但由於導入及維持費用等問題，還還沒有普及。好比 SSH 和 FTP 協議，服務器與客戶端之間的認證是合乎標準規範的，而且知足了最基本的功能需求上的安全使用級別，所以這些協議的認證能夠拿來直接使用。可是對於 Web 網站的認證功能，可以知足其安全使用級別的標準規範並不存在，因此只好使用由 Web 應用程序各自實現基於表單的認證方式。不具有共同標準規範的表單認證，在每一個 Web 網站上都會有各不相同的實現方式。若是是全面考慮過安全性能而實現的表單認證，那麼 就可以具有高度的安全等級。但在表單認證的實現中存在問題的 Web 網站也是家常便飯。

• Session 管理及 Cookie 應用基於表單認證的標準規範還沒有有定論，通常會使用 Cookie 來管理 Session（會話）。基於表單認證自己是經過服務器端的 Web 應用，將客戶端發送過來 的用戶 ID 和密碼與以前登陸過的信息作匹配來進行認證的。但鑑於 HTTP 是無狀態協議，以前已認證成功的用戶狀態沒法經過協議層面保存下來。即，沒法實現狀態管理，所以即便當該用戶下一次繼續訪問，也沒法區分他與其餘的用戶。因而咱們會使用 Cookie 來 管理 Session，以彌補 HTTP 協議中不存在的狀態管理功能。

步驟 1： 客戶端把用戶 ID 和密碼等登陸信息放入報文的實體部分， 一般是以 POST 方法把請求發送給服務器。而這時，會使用 HTTPS 通訊來進行 HTML 表單畫面的顯示和用戶輸入數據的發送。
步驟 2： 服務器會發放用以識別用戶的 Session ID。經過驗證從客戶端發送過來的登陸信息進行身份認證，而後把用戶的認證狀態與 Session ID 綁定後記錄在服務器端。 向客戶端返回響應時，會在首部字段 Set-Cookie 內寫入 Session ID（如 PHPSESSID=028a8c…）。你能夠把 Session ID 想象成一種用以區分不一樣用戶的等位號。然而，若是 Session ID 被第三方盜走，對方就能夠假裝成你的身份進行惡意操做了。所以必須防止 Session ID 被盜，或被猜出。爲了作到 這點，Session ID 應使用難以推測的字符串，且服務器端也須要進行 有效期的管理，保證其安全性。另外，爲減輕跨站腳本攻擊（XSS）形成的損失，建議事先在 Cookie 內加上 httponly 屬性。
步驟 3： 客戶端接收到從服務器端發來的 Session ID 後，會將其做爲 Cookie 保存在本地。下次向服務器發送請求時，瀏覽器會自動發送 Cookie，因此 Session ID 也隨之發送到服務器。服務器端可經過驗證接收到的 Session ID 識別用戶和其認證狀態。

除了以上介紹的應用實例，還有應用其餘不一樣方法的案例。另外，不只基於表單認證的登陸信息及認證過程都無標準化的方法,服務器端應如何保存用戶提交的密碼等登陸信息等也沒有標準化。一般，一種安全的保存方法是，先利用給密碼加鹽（salt）1 的方式增長額外信息，再使用散列（hash）函數計算出散列值後保存。可是咱們也常常看到直接保存明文密碼的作法，而這樣的作法具備致使密碼 泄露的風險。
(salt 其實就是由服務器隨機生成的一個字符串，可是要保證長度足夠長，而且是真正隨機生成的。而後把它和密碼字符串相鏈接（先後均可以）生成散列值。當兩個用戶使用了同一個密碼時，因爲隨機生成的 salt 值不一樣，對應的散列值也將是不一樣的。這樣一來，很大程度上減小了密碼特徵，攻擊者也就很難利用本身手中的密碼特徵庫進行破解。)
如下是往日學習總結，有須要的盆友能夠去看看噢~~
TCP/IP基礎總結性學習（1） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（2） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（3） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（4） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（5） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（6） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（7） - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...
前端面試實習題目總結： - 我的文章 - SegmentFault 思否 https://segmentfault.com/a/11...