HTTP通信中常見認證方式的安全性分析

高度

摘要

隨著互聯網與更多傳統行業的深度融合發展，網絡應用中需要進行認證的場景越來越多，保證此過程的安全尤為重要。以下本文介紹了HTTP通信中常見的幾種認證方式的原理并對其各自的安全性進行了分析。

【關鍵詞】認證方式 通信安全 加密過程

1前言

隨著互聯網行業的不斷發展，電子商務，電子銀行等傳統行業與互聯網結合的越來越緊密，這些行業都深度涉及用戶的財產和隱私，對安全性要求很高。近年來針對這些網絡業務的網絡欺騙和欺詐也層出不窮，因此有必要對網絡通信的安全引起足夠重視。以下，本文將著重對目前HTTP通信中常見認證方式的原理和安全性進行分析。

2BASIC認證

BASIC基本認證是在HTTP1.0中所采用的一種認證方式，它要求客戶端將輸入的認證信息（用戶名和密碼）經過BASE64編碼后發送給服務器，服務器加以驗證并以結果辨別確認客戶端身份。BASE64編碼按6bit識別，轉換過程是將用戶名密碼等字段以6位二進制重新劃分，分完若有不足6位的加0處理，并據此用BASE64編碼表重新編碼，服務器段據此解碼并與用戶數據加以比較。BASE64只是一種編碼方式，沒有進行加密，它簡單明了，但有安全性的問題，主要有幾點：

（1）BASIC認證是用base64對用戶名和密碼進行簡單的編碼后發送的，如上文所言，base64非常容易被解碼，可以看做是明文發送，這風險極大。

（2）即使不解碼，竊聽者也可以獲得用戶名和密碼的密文，并轉發給原始服務器，以獲得對服務器的訪問權。

（3）BASIC認證沒有提供完整性保護，竊聽者可以任意修改報文。

（4）BASIC對通信雙方沒有認證過程，即雙方都無法確認身份。

3DIGEST認證

DIGEST認證可以看作是BASIC認證的改良方案。它的基本流程和BASIC相似，只是并不傳送用戶名密碼等直接信息，DIGEST采用將服務器端和客戶端在通信過程中各自生成的隨機值與用戶名密碼等敏感信息混合在一起計算MD5值，并在信道里傳送此MD5值的方法避免密碼明文傳送。從安全性上考慮，DIGEST可以比較有效的保證通信安全。它主要有以下特點：

（1）通過傳遞用戶名，密碼等計算出來的摘要來解決明文傳輸密碼的問題。

（2）通過產生隨機數nonce并設置生存期，在通信中檢查報文中的nonce值，一旦超時即丟棄報文，同時在客戶端發出的報文中設置了nc值，nc值要求每次都要比之前那次更大一些，假如第一次報文HC值是1，則第二次報文中nc須大于1，通信過程中服務器檢查nc值，一旦相同則丟棄，通過這些設計可以有效的防止重放攻擊。

（3）DIGEST認證中有檢查完整性的字段qop，當客戶端的響應報文中qop值設為auth-int時即進行完整性校驗。

但是，摘要認證并不是最安全的協議，它有以下問題：1.它不對通信雙方進行身份認證，難以避免身份偽裝和欺騙，且使用上不夠靈活，仍達不到一些網站對安全性的要求。

4SSL認證

SSL是目前被廣泛使用的認證協議，用在HTTPS（HTTP Secure）中通信雙方身份認證及密鑰分發的場景較多。通信安全首先應該保證通信雙方的身份，這在SSL認證中通過證書機制得以確認。首先服務器方向第三方數字證書認證機構（CA Certificate Authority）申請公鑰證書并購買客戶端數字證書。之后服務方將數字證書出售或贈與給需要驗證身份的客戶，雙方據證書進行交互，證書申請和交互過程具體如下：

（1）HTTPS服務器方向數字證書認證機構CA提出公開密鑰的申請。

（2）CA對申請者提供的信息進行審核，審核通過后，CA會對己申請的公開密鑰做數字簽名，將該公開密鑰與公鑰證書進行綁定，然后分配這個證書給申請者。

（3）每當有客戶端發起HTTPS請求時，服務器會將這份公鑰證書發送給客戶端，以進行公開密鑰加密方式通信。如果客戶端提出的資源需要驗證客戶端的身份，服務器也會發送Certificate Request報文，要求客戶端提供證書。

（4）接到證書的客戶端使用CA的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：1.認證服務器的公開密鑰的是真實有效的CA。2.服務器的公開密鑰是值得信賴的。如果服務器要求提供證書，客戶端會把客戶端證書信息以Client Certificate報文發送給服務器。

CA的公開密鑰必須安全地轉交給客戶端。在傳輸過程中要做到這點很難，因此多數瀏覽器會事先植入常用CA的公開密鑰。

（5）雙方通過認證后開始通信。經過以上過程，便可以確信雙方的身份，但這里存在前提，CA的身份和證書絕對可靠。CA作為中介解決公鑰的分發問題。越大越知名的CA越可信，所以現在很多瀏覽器都內置了知名CA的公鑰。從算法角度講，SSL證書用公鑰加密體制進行加密，例如常見的RSA算法，對極大整數做因數分解的難度決定了RSA算法的可靠性。目前的技術還沒有辦法在有效時間內破解足夠密鑰長度的RSA算法，這也保證了第三方難以通過技術手段進行偽裝。SSL認證補齊了HTTP通信中的身份認證的漏洞，但SSL也有成本，首先雙方的證書都需要向CA方購買，同時為了保證SSL正常安全的運營也需要付出成本。要注意的是，SSL客戶端的認證能證明客戶端計算機的身份，但無法證明操作者是客戶本人，所以需要與用戶名/密碼的表單認證或其他認證模式配合使用。

5表單認證

由于安全和便利性上存在的不足，BASIC和DIGEST認證應用的場景很少。幾乎所有網站和應用程序還是采用了最基本的表單認證，即用戶名/密碼的驗證方式，但表單認證的過程并沒有標準化，在不同的網站上都有不同的實現方式，所以安全性也參差不一。HTTP協議默認是明文傳輸的，所以表單認證必須與其他加密認證（比如SSL）配合使用，否則極不安全。

6其他認證

除了以上認證方式外，目前還有通過手機號+驗證碼，通過不同網站間授權登錄等認證方式，但也存在安全問題。以手機號+驗證碼方式舉例，從服務方來說，這可以獲得與用戶的通信渠道，可以主動進行信息推送和宣傳，缺點是每次用戶登錄都需要服務方支付短信費用。從客戶端來講，隱私得不到保護，手機號可能被泄露，生活被打擾。最重要的是也不夠方便和安全，手機不在手邊會很不方便，而且很多人還是習慣于設置簡單易記的密碼，一旦手機遺失更有可能會造成損失。

7總結

總的來說，隨著互聯網行業的發展，安全威脅的與日俱增，HTTP協議下的認證技術也在持續的發展中，目前認證模式也逐漸發展到用戶名/密碼加生物特征如指紋等的配合使用，這應該說是比較安全的。但需要指出的是，網絡安全中人的安全意識也尤為重要。

參考文獻

[1]于均良.上野宣.圖解HTTP[M].譯.北京：人民郵電出版社，2014.endprint