HTTP通信中常見認(rèn)證方式的安全性分析

高度

摘要

隨著互聯(lián)網(wǎng)與更多傳統(tǒng)行業(yè)的深度融合發(fā)展，網(wǎng)絡(luò)應(yīng)用中需要進(jìn)行認(rèn)證的場景越來越多，保證此過程的安全尤為重要。以下本文介紹了HTTP通信中常見的幾種認(rèn)證方式的原理并對其各自的安全性進(jìn)行了分析。

【關(guān)鍵詞】認(rèn)證方式 通信安全 加密過程

1前言

隨著互聯(lián)網(wǎng)行業(yè)的不斷發(fā)展，電子商務(wù)，電子銀行等傳統(tǒng)行業(yè)與互聯(lián)網(wǎng)結(jié)合的越來越緊密，這些行業(yè)都深度涉及用戶的財(cái)產(chǎn)和隱私，對安全性要求很高。近年來針對這些網(wǎng)絡(luò)業(yè)務(wù)的網(wǎng)絡(luò)欺騙和欺詐也層出不窮，因此有必要對網(wǎng)絡(luò)通信的安全引起足夠重視。以下，本文將著重對目前HTTP通信中常見認(rèn)證方式的原理和安全性進(jìn)行分析。

2BASIC認(rèn)證

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

（1）BASIC認(rèn)證是用base64對用戶名和密碼進(jìn)行簡單的編碼后發(fā)送的，如上文所言，base64非常容易被解碼，可以看做是明文發(fā)送，這風(fēng)險(xiǎn)極大。

（2）即使不解碼，竊聽者也可以獲得用戶名和密碼的密文，并轉(zhuǎn)發(fā)給原始服務(wù)器，以獲得對服務(wù)器的訪問權(quán)。

（3）BASIC認(rèn)證沒有提供完整性保護(hù)，竊聽者可以任意修改報(bào)文。

（4）BASIC對通信雙方?jīng)]有認(rèn)證過程，即雙方都無法確認(rèn)身份。

3DIGEST認(rèn)證

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

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

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

（3）DIGEST認(rèn)證中有檢查完整性的字段qop，當(dāng)客戶端的響應(yīng)報(bào)文中qop值設(shè)為auth-int時(shí)即進(jìn)行完整性校驗(yàn)。

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

4SSL認(rèn)證

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

（1）HTTPS服務(wù)器方向數(shù)字證書認(rèn)證機(jī)構(gòu)CA提出公開密鑰的申請。

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

（3）每當(dāng)有客戶端發(fā)起HTTPS請求時(shí)，服務(wù)器會將這份公鑰證書發(fā)送給客戶端，以進(jìn)行公開密鑰加密方式通信。如果客戶端提出的資源需要驗(yàn)證客戶端的身份，服務(wù)器也會發(fā)送Certificate Request報(bào)文，要求客戶端提供證書。

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

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

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

5表單認(rèn)證

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

6其他認(rèn)證

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

7總結(jié)

總的來說，隨著互聯(lián)網(wǎng)行業(yè)的發(fā)展，安全威脅的與日俱增，HTTP協(xié)議下的認(rèn)證技術(shù)也在持續(xù)的發(fā)展中，目前認(rèn)證模式也逐漸發(fā)展到用戶名/密碼加生物特征如指紋等的配合使用，這應(yīng)該說是比較安全的。但需要指出的是，網(wǎng)絡(luò)安全中人的安全意識也尤為重要。

參考文獻(xiàn)

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