摘要：步驟接收到狀態(tài)碼的客戶端為了通過認(rèn)證，需要將用戶及密碼發(fā)送給服務(wù)器。所謂雙因素認(rèn)證就是指，認(rèn)證過程中不僅需要密碼這一個因素，還需要申請認(rèn)證者提供其他持有信息，從而作為另一個因素，與其組合使用的認(rèn)證方式。

某些 Web 頁面只想讓特定的人瀏覽，或者干脆僅本人可見。為達到這個目標(biāo)，必不可少的就是認(rèn)證功能。下面我們一起來學(xué)習(xí)一下認(rèn)證機制。

一.　何為認(rèn)證

1.計算機本身無法判斷坐在顯示器前的使用者的身份。進一步說，也無法確認(rèn)網(wǎng)絡(luò)的那頭究竟有誰?？梢?，為了弄清究竟是誰在訪問服務(wù)器，就得讓對方的客戶端自報家門?？墒?，就算正在訪問服務(wù)器的對方聲稱自己是ueno，身份是否屬實這點卻也無從談起。為確認(rèn) ueno 本人是否真的具有訪問系統(tǒng)的權(quán)限， 就需要核對“登錄者本人才知道的信息”、“登錄者本人才會有的信息”。

2.核對的信息通常是指以下這些:
密碼：只有本人才會知道的字符串信息。
動態(tài)令牌：僅限本人持有的設(shè)備內(nèi)顯示的一次性密碼。
數(shù)字證書：僅限本人（終端）持有的信息。
生物認(rèn)證：指紋和虹膜等本人的生理信息。
IC 卡等：僅限本人持有的信息。

但是，即便對方是假冒的用戶，只要能通過用戶驗證，那么計算機就會默認(rèn)是出自本人的行為。因此，掌控機密信息的密碼絕不能讓他人得到，更不能輕易地就被破解出來。HTTP 使用的認(rèn)證方式 HTTP/1.1 使用的認(rèn)證方式如下所示。 BASIC 認(rèn)證（基本認(rèn)證） DIGEST 認(rèn)證（摘要認(rèn)證）SSL 客戶端認(rèn)證 FormBase 認(rèn)證（基于表單認(rèn)證）此外，還有 Windows 統(tǒng)一認(rèn)證（Keberos 認(rèn)證、NTLM 認(rèn)證）。

二.BASIC 認(rèn)證BASIC

認(rèn)證（基本認(rèn)證）是從 HTTP/1.0 就定義的認(rèn)證方式。即便是現(xiàn)在仍有一部分的網(wǎng)站會使用這種認(rèn)證方式。是 Web 服務(wù)器與通信客戶端之間進行的認(rèn)證方式。

1.BASIC 認(rèn)證的認(rèn)證步驟

步驟 1： 當(dāng)請求的資源需要 BASIC 認(rèn)證時，服務(wù)器會隨狀態(tài)碼 401 Authorization Required，返回帶 WWW-Authenticate 首部字段的響應(yīng)。 該字段內(nèi)包含認(rèn)證的方式（BASIC） 及 Request-URI 安全域字符串 （realm）。
步驟 2： 接收到狀態(tài)碼 401 的客戶端為了通過 BASIC 認(rèn)證，需要將用戶 ID 及密碼發(fā)送給服務(wù)器。發(fā)送的字符串內(nèi)容是由用戶 ID 和密碼構(gòu)成，兩者中間以冒號（:）連接后，再經(jīng)過 Base64 編碼處理。

假設(shè)用戶 ID 為 guest，密碼是 guest，連接起來就會形成 guest:guest 這樣的字符串。然后經(jīng)過 Base64 編碼，最后的結(jié)果即是 Z3Vlc3Q6Z3Vlc3Q=。把這串字符串寫入首部字段 Authorization 后，發(fā)送請求。
當(dāng)用戶代理為瀏覽器時，用戶僅需輸入用戶 ID 和密碼即可，之后，瀏覽器會自動完成到 Base64 編碼的轉(zhuǎn)換工作。

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

BASIC 認(rèn)證雖然采用 Base64 編碼方式，但這不是加密處理。不需要任何附加信息即可對其解碼。換言之，由于明文解碼后就是用戶 ID 和密碼，在 HTTP 等非加密通信的線路上進行 BASIC 認(rèn)證的過程中，如果被人竊聽，被盜的可能性極高。另外，除此之外想再進行一次 BASIC 認(rèn)證時，一般的瀏覽器卻無法實現(xiàn)認(rèn)證注銷操作，這也是問題之一。BASIC 認(rèn)證使用上不夠便捷靈活，且達不到多數(shù) Web 網(wǎng)站期望的安全性等級，因此它并不常用。

三.　DIGEST 認(rèn)證

為彌補 BASIC 認(rèn)證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認(rèn)證。 DIGEST 認(rèn)證同樣使用質(zhì)詢 / 響應(yīng)的方式 （challenge/response），但不會像 BASIC 認(rèn)證那樣直接發(fā)送明文密碼。

1.所謂質(zhì)詢響應(yīng)方式是指，一開始一方會先發(fā)送認(rèn)證要求給另一方，接著使用從另一方那接收到的質(zhì)詢碼計算生成響應(yīng)碼。最后將響應(yīng)碼返回給對方進行認(rèn)證的方式。

因為發(fā)送給對方的只是響應(yīng)摘要及由質(zhì)詢碼產(chǎn)生的計算結(jié)果，所以比起 BASIC 認(rèn)證，密碼泄露的可能性就降低了。

DIGEST 認(rèn)證的認(rèn)證步驟:

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

步驟 2： 接收到 401 狀態(tài)碼的客戶端，返回的響應(yīng)中包含 DIGEST 認(rèn)證必須的首部字段 Authorization 信息。 首部字段 Authorization 內(nèi)必須包含 username、realm、nonce、uri 和 response 的字段信息。其中，realm 和 nonce 就是之前從服務(wù)器接收到 的響應(yīng)中的字段。username 是 realm 限定范圍內(nèi)可進行認(rèn)證的用戶名。 uri（digest-uri）即 Request-URI 的值，但考慮到經(jīng)代理轉(zhuǎn)發(fā)后 Request-URI 的值可能被修改，因此事先會復(fù)制一份副本保存在 uri 內(nèi)。response 也可叫做 Request-Digest，存放經(jīng)過 MD5 運算后的密碼字符串，形成響應(yīng)碼。響應(yīng)中其他的實體請參見第 6 章的請求首部字段 Authorization。另外，有關(guān) Request-Digest 的計算規(guī)則較復(fù)雜，有興趣的讀者不妨深入 學(xué)習(xí)一下 RFC2617。

步驟 3： 接收到包含首部字段 Authorization 請求的服務(wù)器，會確認(rèn)認(rèn)證信息的正確性。認(rèn)證通過后則返回包含 Request-URI 資源的響應(yīng)。 并且這時會在首部字段 Authentication-Info 寫入一些認(rèn)證成功的相關(guān)信息。DIGEST 認(rèn)證提供了高于 BASIC 認(rèn)證的安全等級，但是和 HTTPS 的客戶端認(rèn)證相比仍舊很弱。DIGEST 認(rèn)證提供防止密碼被竊聽的保護機制，但并不存在防止用戶偽裝的保護機制。DIGEST 認(rèn)證和 BASIC 認(rèn)證一樣，使用上不那么便捷靈活，且仍達不到多數(shù) Web 網(wǎng)站對高度安全等級的追求標(biāo)準(zhǔn)。因此它的適用范圍也 有所受限。

四.SSL 客戶端認(rèn)證

從使用用戶 ID 和密碼的認(rèn)證方式方面來講，只要二者的內(nèi)容正確， 即可認(rèn)證是本人的行為。但如果用戶 ID 和密碼被盜，就很有可能被第三者冒充。利用 SSL 客戶端認(rèn)證則可以避免該情況的發(fā)生。SSL 客戶端認(rèn)證是借由 HTTPS 的客戶端證書完成認(rèn)證的方式。憑借客戶端證書（在 HTTPS 一章已講解）認(rèn)證，服務(wù)器可確認(rèn)訪問是否來自已登錄的客戶端。

SSL 客戶端認(rèn)證的認(rèn)證步驟為達到 SSL 客戶端認(rèn)證的目的，需要事先將客戶端證書分發(fā)給客戶端，且客戶端必須安裝此證書。

步驟 1： 接收到需要認(rèn)證資源的請求，服務(wù)器會發(fā)送 Certificate Request 報文，要求客戶端提供客戶端證書。
步驟 2： 用戶選擇將發(fā)送的客戶端證書后，客戶端會把客戶端證書信息以 Client Certificate 報文方式發(fā)送給服務(wù)器。

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

步驟 3： 服務(wù)器驗證客戶端證書驗證通過后方可領(lǐng)取證書內(nèi)客戶端的公開密鑰，然后開始 HTTPS 加密通信。

SSL 客戶端認(rèn)證采用雙因素認(rèn)證在多數(shù)情況下，SSL客戶端認(rèn)證不會僅依靠證書完成認(rèn)證，一般會和基于表單認(rèn)證（稍后講解）組合形成一種雙因素認(rèn)證（Two-factor authentication）來使用。所謂雙因素認(rèn)證就是指，認(rèn)證過程中不僅需要密碼這一個因素，還需要申請認(rèn)證者提供其他持有信息，從而作為另一個因素，與其組合使用的認(rèn)證方式。換言之，第一個認(rèn)證因素的 SSL 客戶端證書用來認(rèn)證客戶端計算機，另一個認(rèn)證因素的密碼則用來確定這是用戶本人的行為。通過雙因素認(rèn)證后，就可以確認(rèn)是用戶本人正在使用匹配正確的計算機訪問服務(wù)器。

SSL 客戶端認(rèn)證必要的費用使用 SSL 客戶端認(rèn)證需要用到客戶端證書。而客戶端證書需要支付一 定費用才能使用。這里提到的費用是指，從認(rèn)證機構(gòu)購買客戶端證書的費用，以及服務(wù) 器運營者為保證自己搭建的認(rèn)證機構(gòu)安全運營所產(chǎn)生的費用。每個認(rèn)證機構(gòu)頒發(fā)客戶端證書的費用不盡相同，平攤到一張證書上，一年費用約幾萬至十幾萬日元。服務(wù)器運營者也可以自己搭建認(rèn)證機構(gòu)，但要維持安全運行就會產(chǎn)生相應(yīng)的費用。

五.基于表單認(rèn)證

基于表單的認(rèn)證方法并不是在 HTTP 協(xié)議中定義的?？蛻舳藭蚍?wù)器上的 Web 應(yīng)用程序發(fā)送登錄信息（Credential），按登錄信息的驗證結(jié)果認(rèn)證。根據(jù) Web 應(yīng)用程序的實際安裝，提供的用戶界面及認(rèn)證方式也各不相同。

圖：基于表單認(rèn)證示例（Google）
多數(shù)情況下，輸入已事先登錄的用戶 ID（通常是任意字符串或郵件 地址）和密碼等登錄信息后，發(fā)送給 Web 應(yīng)用程序，基于認(rèn)證結(jié)果 來決定認(rèn)證是否成功。

認(rèn)證多半為基于表單認(rèn)證

由于使用上的便利性及安全性問題，HTTP 協(xié)議標(biāo)準(zhǔn)提供的 BASIC 認(rèn)證和 DIGEST 認(rèn)證幾乎不怎么使用。另外，SSL 客戶端認(rèn)證雖然具有高度的安全等級，但因為導(dǎo)入及維持費用等問題，還尚未普及。比如 SSH 和 FTP 協(xié)議，服務(wù)器與客戶端之間的認(rèn)證是合乎標(biāo)準(zhǔn)規(guī)范的，并且滿足了最基本的功能需求上的安全使用級別，因此這些協(xié)議的認(rèn)證可以拿來直接使用。但是對于 Web 網(wǎng)站的認(rèn)證功能，能夠滿足其安全使用級別的標(biāo)準(zhǔn)規(guī)范并不存在，所以只好使用由 Web 應(yīng)用程序各自實現(xiàn)基于表單的認(rèn)證方式。不具備共同標(biāo)準(zhǔn)規(guī)范的表單認(rèn)證，在每個 Web 網(wǎng)站上都會有各不相同的實現(xiàn)方式。如果是全面考慮過安全性能而實現(xiàn)的表單認(rèn)證，那么 就能夠具備高度的安全等級。但在表單認(rèn)證的實現(xiàn)中存在問題的 Web 網(wǎng)站也是屢見不鮮。

Session 管理及 Cookie 應(yīng)用基于表單認(rèn)證的標(biāo)準(zhǔn)規(guī)范尚未有定論，一般會使用 Cookie 來管理 Session（會話）?；诒韱握J(rèn)證本身是通過服務(wù)器端的 Web 應(yīng)用，將客戶端發(fā)送過來 的用戶 ID 和密碼與之前登錄過的信息做匹配來進行認(rèn)證的。但鑒于 HTTP 是無狀態(tài)協(xié)議，之前已認(rèn)證成功的用戶狀態(tài)無法通過協(xié)議層面保存下來。即，無法實現(xiàn)狀態(tài)管理，因此即使當(dāng)該用戶下一次繼續(xù)訪問，也無法區(qū)分他與其他的用戶。于是我們會使用 Cookie 來 管理 Session，以彌補 HTTP 協(xié)議中不存在的狀態(tài)管理功能。

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

除了以上介紹的應(yīng)用實例，還有應(yīng)用其他不同方法的案例。另外，不僅基于表單認(rèn)證的登錄信息及認(rèn)證過程都無標(biāo)準(zhǔn)化的方法,服務(wù)器端應(yīng)如何保存用戶提交的密碼等登錄信息等也沒有標(biāo)準(zhǔn)化。通常，一種安全的保存方法是，先利用給密碼加鹽（salt）1 的方式增加額外信息，再使用散列（hash）函數(shù)計算出散列值后保存。但是我們也經(jīng)?？吹街苯颖４婷魑拿艽a的做法，而這樣的做法具有導(dǎo)致密碼 泄露的風(fēng)險。
(salt 其實就是由服務(wù)器隨機生成的一個字符串，但是要保證長度足夠長，并且是真正隨機生成的。然后把它和密碼字符串相連接（前后都可以）生成散列值。當(dāng)兩個用戶使用了同一個密碼時，由于隨機生成的 salt 值不同，對應(yīng)的散列值也將是不同的。這樣一來，很大程度上減少了密碼特征，攻擊者也就很難利用自己手中的密碼特征庫進行破解。)
以下是往日學(xué)習(xí)總結(jié)，有需要的盆友可以去看看噢~~
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（1） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（2） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（3） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（4） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（5） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（6） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（7） - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...
前端面試實習(xí)題目總結(jié)： - 個人文章 - SegmentFault 思否 https://segmentfault.com/a/11...