摘要：所以我們今天只談前端加密，一個(gè)部分人認(rèn)為沒(méi)有意義的工作。在中，認(rèn)證過(guò)程使用了非對(duì)稱加密算法，非認(rèn)證過(guò)程中使用了對(duì)稱加密算法。非對(duì)稱加密上文中我們討論了前端的哈希加密以及應(yīng)用的場(chǎng)景。

前端安全是Web安全的一部分，常見的安全問(wèn)題會(huì)有XSS、CSRF、SQL注入等，然而這些已經(jīng)在程師界得到了相當(dāng)高的重視并且有了很成熟的解決方案。 所以我們今天只談前端“加密”，一個(gè)部分人認(rèn)為沒(méi)有意義的工作。 有爭(zhēng)議的事情總是那么因崔斯汀，接下來(lái)就讓我們談?wù)勄岸藗鬏斨械臄?shù)據(jù)“加密” 。

前端傳輸?shù)臄?shù)據(jù)我們應(yīng)該用什么算法加密，如何組織整個(gè)加密過(guò)程呢？ 一般有幾種做法：

JavaScript 加密后傳輸

瀏覽器插件內(nèi)進(jìn)行加密傳輸

Https 傳輸

在這里其實(shí) HTTPS 是終極解決方案，所以文章對(duì)于仍在使用 HTTP 建站的小伙伴更有幫助。本文中將討論第一種方法，也就是使用 JavaScript "加密"。使用雙引號(hào)是因?yàn)檫@里面分為兩種手段，一是使用數(shù)據(jù)摘要進(jìn)行消息雜湊，二是使用非對(duì)稱加密算法對(duì)明文進(jìn)行加密。

嚴(yán)格意義來(lái)說(shuō)第一種手段并非加密，而是一種信息摘要的應(yīng)用，為了闡述方便下文統(tǒng)統(tǒng)使用加密一詞。在進(jìn)行下文之前，需要簡(jiǎn)單的介紹幾個(gè)概念：

上圖中我們可以明顯看到哈希和加密是兩個(gè)不同的東西，主要有兩點(diǎn)不同：

哈希算法通常用于數(shù)據(jù)摘要，生成相同長(zhǎng)度的文本。而加密算法生成的密文長(zhǎng)度與明文長(zhǎng)度有關(guān)。

哈希算法是不可逆的，而加密算法是可逆的。

在加密算法中又分為對(duì)稱加密（symmetric encryption）和非對(duì)稱加密（asymmetric encryption）。非對(duì)稱加密算法中，加密密鑰和解密密鑰是不同的，分為私鑰和公鑰，我們熟知的 RSA 就是一種非對(duì)稱加密算法。而對(duì)稱加密中，加密和解密都是用同一個(gè)密鑰，如 AES / DES。從性能上來(lái)說(shuō)，非對(duì)稱加密相對(duì)于對(duì)稱加密要慢很多。在 HTTPS 中，認(rèn)證過(guò)程使用了非對(duì)稱加密算法，非認(rèn)證過(guò)程中使用了對(duì)稱加密算法。

在 HTTP 協(xié)議下，數(shù)據(jù)是明文傳輸，傳輸過(guò)程中網(wǎng)絡(luò)嗅探可直接獲取其中的數(shù)據(jù)。 如用戶的密碼和信用卡相關(guān)的資料，一旦被中間人獲取，會(huì)給用戶帶來(lái)極大的安全隱患。另一方面在非加密的傳輸過(guò)程中，攻擊者可更改數(shù)據(jù)或插入惡意的代碼等。HTTPS 的誕生就是為了解決中間人攻擊的問(wèn)題，但如今 HTTPS 的使用情況在國(guó)內(nèi)并不樂(lè)觀，基本是因?yàn)槌杀净蛘咝阅艿目剂俊?/p>

Q：那么問(wèn)題來(lái)了，如果仍然使用 HTTP 協(xié)議怎么樣一定程度保證用戶的數(shù)據(jù)安全？ 
A：前端加密，即在數(shù)據(jù)發(fā)送前將數(shù)據(jù)進(jìn)行哈希或使用公鑰加密。如果數(shù)據(jù)被中間人獲取，拿到的則不再是明文。

設(shè)想在如今公共 WIFI 流行的今天，一旦某一個(gè) AP 的流量被攻擊者劫持，如果密碼和用戶名都是明文，那么攻擊者將輕而易舉的使用這些資料進(jìn)行 Replay 登錄。更糟糕的是很多用戶在不同的網(wǎng)站使用相同的賬號(hào)信息，用戶的隱私蕩然無(wú)存。作為網(wǎng)站服務(wù)提供者，網(wǎng)站設(shè)計(jì)和開發(fā)人員應(yīng)該為用戶提供相對(duì)安全的服務(wù)，這是一種責(zé)任也是一種情懷。

另外如果前端使用哈希算法，不僅可以幫助后端分擔(dān)部分計(jì)算壓力，還可以增加撞庫(kù)成本。具體的討論將在下文繼續(xù)。

前面說(shuō)過(guò)使用 JavaScript 加密有兩種方式，一是使用哈希進(jìn)行信息摘要，一種是使用非對(duì)稱加密。在國(guó)內(nèi)的知名站點(diǎn)中，這兩種方式都有人使用。接下來(lái)我們分別來(lái)深入了解加密過(guò)程，探討下如何應(yīng)對(duì)不同的場(chǎng)景。

為了避免傳輸過(guò)程中的明文風(fēng)險(xiǎn)，前端可以在發(fā)送敏感數(shù)據(jù)前對(duì)其加密，如密碼。由于哈希算法的不可逆性，中間人無(wú)法從截取的數(shù)據(jù)中得知用戶的密碼信息。但是這里有一個(gè)問(wèn)題，攻擊者仍然可以使用拿到的哈希值進(jìn)行直接登錄。使用前端加密如何避免中間人重放攻擊？帶著這個(gè)問(wèn)題，我們回顧下后臺(tái)如何驗(yàn)證用戶。

很多站點(diǎn)后臺(tái)對(duì)于用戶密碼處理也是用哈希算法，一方面因?yàn)椴恍枰獙⒚芪慕饷艹擅魑膩?lái)比對(duì)密碼，另一方面是一旦加密算法和密鑰泄露，那么整個(gè)用戶資料庫(kù)就相當(dāng)于明文存儲(chǔ)了。如果前端傳過(guò)來(lái)的是明文，那么在注冊(cè)時(shí)將其哈希，存入數(shù)據(jù)庫(kù)。登錄時(shí)，將密碼哈希和數(shù)據(jù)庫(kù)對(duì)應(yīng)的數(shù)據(jù)比對(duì)，若一致則說(shuō)明密碼正確。

如果我們使用 Salt 是否可以解決問(wèn)題？如果前端傳過(guò)來(lái)的是加了 salt 的哈希值，我們需要后端存有同一份 salt ，用其和數(shù)據(jù)庫(kù)的加密密碼哈希，然后與前端傳過(guò)來(lái)的哈希值比對(duì)。兩個(gè)過(guò)程的對(duì)比見下圖：

很容易知道，如果 Salt 不是每次登陸不同，那么攻擊者仍可以使用加密后的密碼進(jìn)行直接登陸，所以必須使用動(dòng)態(tài) Salt。動(dòng)態(tài) Salt 有很多方法，可以是動(dòng)態(tài)的 Token，也可以直接使用現(xiàn)成的驗(yàn)證碼。 這當(dāng)中使用驗(yàn)證碼是對(duì)后臺(tái)系統(tǒng)改動(dòng)較小且效果不錯(cuò)的，我們來(lái)看看怎么樣結(jié)合驗(yàn)證碼進(jìn)行前端加密。

前端先將密碼哈希，然后和用戶輸入的驗(yàn)證碼進(jìn)行哈希，得到的結(jié)果作為密碼字段發(fā)送給服務(wù)器。服務(wù)器先確認(rèn)驗(yàn)證碼正確，然后再進(jìn)行密碼驗(yàn)證，否則直接返回驗(yàn)證碼錯(cuò)誤信息。

這種實(shí)踐保證了密碼在傳輸過(guò)程中的資料安全，即使攻擊者拿到了數(shù)據(jù)也無(wú)法重放。圖形化驗(yàn)證碼更是增加了難度。另一方面該實(shí)踐大大增加了撞庫(kù)的成本。

前端加密一定程度保障了傳輸過(guò)程中的資料安全，那么會(huì)不會(huì)有對(duì)兩端（客戶端和服務(wù)器）有安全幫助呢？ 有幫助，使用一些前端加密手段，可以增加拖庫(kù)后的數(shù)據(jù)破解難度。但是之前介紹的驗(yàn)證碼方法不具有這樣的功能，因?yàn)閿?shù)據(jù)庫(kù)存的仍是明文密碼哈希后的結(jié)果，那么攻擊者可以繞過(guò)前端加密，可以直接暴力破解。

使用怎么樣的前端加密方法可以增加拖庫(kù)后的數(shù)據(jù)破解難度？從兩個(gè)方面分別去思考，一是降低破解速度，二是需要前端加密結(jié)果影響數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)。數(shù)據(jù)被暴力破解出來(lái)的時(shí)間與哈希算法速度負(fù)相關(guān)。

我們知道暴力破解即是使用相同的算法把常用的字符組跑一遍，如果結(jié)果相同那么就猜中明文了。如果算法越快，便能更快的破解。例如 MD5 加密一次耗費(fèi)1微秒，那么攻擊者一秒鐘就可以猜大約 100萬(wàn)個(gè)詞組。所以為了減慢破解速度，我們需要增加破解的時(shí)間，一個(gè)直接的方法就是使用更慢的算法，我們可以把常用的MD5算法替換為 bcrypt，PBKDF2 等慢算法。

對(duì)于需要前端加密結(jié)果影響數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)，即為后端加密把前端加密結(jié)果當(dāng)做明文密碼，那么存在庫(kù)里的密碼便是前端哈希加上后端加密的結(jié)果。由于慢的算法會(huì)增加服務(wù)器計(jì)算壓力，當(dāng)我們把一部分哈希工作拿到前端，即減慢了加密速度，減輕了服務(wù)器壓力，也順帶完成了前端加密的工作。

加密速度減慢一定程度會(huì)降低用戶體驗(yàn)，這也是一部分站點(diǎn)未啟用 https 的原因之一。但是因?yàn)槲覀兊那岸思用苤粫?huì)用在不常使用的登錄和注冊(cè)上，所以不會(huì)影響網(wǎng)站整體的體驗(yàn)。

綜上，我們可以使用更慢的算法，加之視前端哈希結(jié)果為明文密碼，便可增加拖庫(kù)破解的成本。既然增加了破解的成本，撞庫(kù)的成本也同樣增加了。為了避免攻擊者先前使用前后端加密生成的新字典，我們需要加鹽，并不定期更新鹽值。下圖文是使用過(guò)期 Salt 的方法描述：

前端加密使用定期刷新的 Salt，哈希后生成密文，再經(jīng)過(guò)后端加密后即為用于比對(duì)的密文。數(shù)據(jù)庫(kù)中的密碼哈希值跟著 Salt 進(jìn)行變化，前后端需要有一套salt的更新機(jī)制。

回顧前端哈希的方法，解決了中間人攻擊重放、加大了拖庫(kù)破解的難度。雖然這些方法都不能完全保證用戶安全，但是作為站點(diǎn)服務(wù)者，應(yīng)該視用戶為上帝嘛。這些方法也不過(guò)就是幾行代碼的事，但是卻能一定程度的避免了用戶賬號(hào)被盜等風(fēng)險(xiǎn)。

上文中我們討論了前端的哈希加密以及應(yīng)用的場(chǎng)景。對(duì)于十足的安全控來(lái)說(shuō)，這樣的措施對(duì)于有心的攻擊者基本沒(méi)有用。那么我們可以采用更強(qiáng)的措施保障傳輸中的敏感數(shù)據(jù)安全。

之前有說(shuō)過(guò)加密算法分為對(duì)稱加密和非對(duì)稱加密，因?yàn)榍岸说耐该餍裕褂肑avaScript來(lái)進(jìn)行對(duì)稱加密是不可能的了，那么只剩下了非對(duì)稱加密這個(gè)選擇。經(jīng)過(guò)筆者幾天的調(diào)研發(fā)現(xiàn)，某鵝某浪的部分登錄頁(yè)面采用非對(duì)稱加密對(duì)密碼加密。這些站點(diǎn)目前都還是使用 http 協(xié)議，這樣的安全措施一定程度保證了用戶的密碼安全。

前端使用非對(duì)稱加密原理很簡(jiǎn)單，前后端共用一套加密解密算法，前端使用公鑰對(duì)數(shù)據(jù)加密，后端使用私鑰將數(shù)據(jù)解密為明文。中間攻擊人拿到密文，如果沒(méi)有私鑰的話是沒(méi)辦法破解的。

可能有人會(huì)指出加密算法一旦被破解，這一套安全措施就沒(méi)用了。況且 JavaScript 的生成安全隨機(jī)數(shù)還是個(gè)問(wèn)題，所以其實(shí)這是用不了 https 的權(quán)衡之計(jì)。在沒(méi)有 https 的情況下，使用 JavaScript 非對(duì)稱加密或者 插件加密通訊是比較好的替代方法，后者優(yōu)于前者。

作為一個(gè)前端開發(fā)者，我們眼里不應(yīng)該只充斥各種框架，更不能被旁人一句沒(méi)有意義的話給擊退。任何解決方案都有其適用的范圍，世界上根本就沒(méi)有銀彈，安全問(wèn)題亦是如此。所以根據(jù)實(shí)際的情況采取符合自己的安全解決方案很重要，即使辦法不是 100% 有效，也不能放棄那 1% 可以為用戶保障安全的機(jī)會(huì)。

反爬蟲
文章來(lái)源：http://bigsec.com/