前端面試查漏補缺--(八) 前端加密
本系列最開始是為了自己面試準備的.後來發現整理越來越多,差不多有十二萬字元,最後決定還是分享出來給大家.
為了分享整理出來,花費了自己大量的時間,起碼是隻自己用的三倍時間.如果喜歡的話,歡迎收藏,關注我!謝謝!
合集篇: 前端面試查漏補缺--Index篇(12萬字符合集) 包含目前已寫好的系列其他十幾篇文章. 強烈建議點贊,關注,謝謝!~
後續還會繼續新增 設計模式 , 前端工程化 , 專案流程,部署,閉環 等內容.如果覺得內容不錯的話歡迎收藏,關注我!謝謝!
求一份內推目前本人也在準備跳槽,希望各位大佬和HR小姐姐可以內推一份靠譜的 武漢 內推!郵箱:[email protected].謝謝啦!~
前端加密的意義
這是一個繞不開的話題,肯定有很多看法.但我看來:前端加密看起來有意義,但有時候看起來並沒有"意義". 但總體來看是有意義的,打個比喻: 既然市面上大部分鎖都可以在20分鐘內撬開，那門上裝鎖是否還有意義？
有意義:在 HTTP 協議下，資料是明文傳輸，傳輸過程中網路嗅探可直接獲取其中的資料。 如使用者的密碼和信用卡相關的資料，一旦被中間人獲取，會給使用者帶來極大的安全隱患。另一方面在非加密的傳輸過程中，攻擊者可更改資料或插入惡意的程式碼等。那麼前端加密的意義: 即在資料傳送前將資料進行雜湊或使用公鑰加密。如果資料被中間人獲取，拿到的則不再是明文。
當然還有其他一些優點:例如避免後端等列印日誌直接暴露明文密碼,還可以避免明文撞庫等.
沒有"意義":前端加密，其實只能 防君子不能防小人。 前端系統的控制權是完全在使用者手裡的，也就是說，前端做什麼事情，使用者有完全的控制權。即使前端加密不可以防範中間人攻擊,包括HTTPS,因為中間還是存在著各種代理,客戶端代理,服務端代理.是很難做到不被劫持的.
這裡簡單說下:
- 加密了也無法解決重放的問題，你發給伺服器端的雖然是加密後的資料，但是黑客攔截之後，把加密之後的資料重發一遍，依然是驗證通過的。直接監聽到你所謂的密文，然後用指令碼發起一個http請求就可以登入上去了。 http在網路上是明文傳輸的，代理和閘道器都能夠看到所有的資料，在同一區域網內也可以被嗅探到。加密也沒有提高什麼攻擊難度，因為攻擊者就沒必要去解密原始密碼，能登入上去就表示目標已經實現了，所以，難度沒有提高。
- 既然是加密，那麼加密用的金鑰和演算法肯定是儲存在前端的，攻擊者通過檢視原始碼就能得到演算法和金鑰。除非你是通過做瀏覽器外掛，將演算法和金鑰封裝在外掛中，然後加密的時候明文混淆上時間戳，這樣即使黑客攔截到了請求資料，進行重放過程時，也會很快失效。
總結一下:
- 1,安全是前後端都需要做的事,不能前端加密了,後端就不管了.
- 2,HTTPS還是有必要的,只要正確使用了HTTPS連線和伺服器端安全的雜湊演算法，密碼系統都可以是很安全的。
這裡我只是簡單梳理下,如果還有疑惑想深入探(si)討(bi)的,可以看下逼乎上的這篇文章
前端加密的幾種做法
• JavaScript 加密後傳輸(具體可以參考後面的常見加密方法)
• 瀏覽器外掛內進行加密傳輸 (這個用得不是很多,這裡暫不細究)
• Https 傳輸
加密演算法
不同於雜湊(後面會提到)，加密（Encrypt）是將目標文字轉換成具有不同長度的、 可逆的密文 。也就是說加密演算法是可逆的，而且其加密後生成的密文長度和明文字身的長度有關。所以 如果被保護資料在以後需要被還原成明文，則需要使用加密。
在加密演算法中又分為對稱加密（symmetric encryption）和非對稱加密（asymmetric encryption）。
對稱加密
對稱加密採用了對稱密碼編碼技術，它的特點是檔案加密和解密使用相同的金鑰加密.也就是 加密和解密都是用同一個金鑰 ，這種方法在密碼學中叫做對稱加密演算法.
對稱加密演算法使用起來簡單快捷，金鑰較短，且破譯困難，除了資料加密標準（DES），另一個對稱金鑰加密系統是國際資料加密演算法（IDEA），它比DES的加密性好，而且對計算機功能要求也沒有那麼高.
常見的對稱加密演算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES
注意:因為前端的透明性， 對於登入密碼等敏感資訊,就不要使用JavaScript來進行對稱加密. 因為別人可以從前端得到密匙後,可以直接對資訊進行解密!
非對稱加密
非對稱加密演算法需要兩個金鑰：公鑰（publickey）和私鑰（privatekey）。 公鑰與私鑰是一對， 如果用公鑰對資料進行加密，只有用對應的私鑰才能解密；如果用私鑰對資料進行加密，那麼只有用對應的公鑰才能解密。 因為加密和解密使用的是兩個不同的金鑰，所以這種演算法叫作非對稱加密演算法。
非對稱加密演算法實現機密資訊交換的基本過程是：甲方生成一對金鑰並將其中的一把作為公鑰向其它方公開；得到該公鑰的乙方使用該金鑰對機密資訊進行加密後再發送給甲方；甲方再用自己儲存的另一把專用金鑰對加密後的資訊進行解密。甲方只能用其專用金鑰解密由其公鑰加密後的任何資訊。
常見的非對稱加密演算法有：RSA、ECC（移動裝置用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
雜湊加密演算法
雜湊演算法（Hash）
雜湊（Hash）是將目標文字轉換成具有固定長度的字串（或叫做訊息摘要）。當輸入發生改變時，產生的雜湊值也是完全不同的。從數學角度上講，一個雜湊演算法是一個多對一的對映關係，對於目標文字 T，演算法 H 可以將其唯一對映為 R，並且對於所有的 T，R 具有相同的長度，所以 H 不存在逆對映，也就是說 雜湊演算法是不可逆的。
基於雜湊演算法的特性，其適用於該場景：被保護資料僅僅用作比較驗證且不需要還原成明文形式。 比較常用的雜湊演算法是 MD5 和 SHA1 。
我們比較熟悉的使用雜湊儲存資料的例子是：當我們登入某個已註冊網站時，在忘記密碼的情況下需要重置密碼，此時網站會給你發一個隨機的密碼或者一個郵箱啟用連結，而不是將之前的密碼發給你，這就是因為雜湊演算法是不可逆的。
需要注意的是：在 Web 應用中， 在瀏覽器中使用雜湊加密的同時也要在服務端上進行雜湊加密。
服務端雜湊加密原因:一方面因為不需要將密文解密成明文來比對密碼，另一方面是一旦加密演算法和金鑰洩露，那麼整個使用者資料庫就相當於明文儲存了。如果前端傳過來的是明文，那麼在註冊時將其雜湊，存入資料庫。登入時，將密碼雜湊和資料庫對應的資料比對，若一致則說明密碼正確。
現在，對於簡單的雜湊演算法的攻擊方法主要有：尋找碰撞法和窮舉法。所以，為了保證資料的安全，可以 在雜湊演算法的基礎上進一步的加密，常見的方法有：加鹽、慢雜湊、金鑰雜湊、XOR 等。
加鹽（Adding Salt）
加鹽加密是一種對系統登入口令的加密方式，它實現的方式是將每一個口令同一個叫做“鹽”（salt）的 n 位隨機數相關聯。
為了方便理解:這裡引用這位同學的文章進行說明:
使用salt加密，它的基本想法是這樣的：
- 1.使用者註冊時，在密碼上撒一些鹽。生成一種味道，記住味道。
- 2.使用者再次登陸時，在輸入的密碼上撒鹽，聞一聞，判斷是否和原來的味道相同，相同就讓你吃飯。
由於驗證密碼時和最初雜湊密碼時使用相同的鹽值，所以 salt的儲存在資料庫 。並且 這個值是由系統隨機產生的 ，而非硬編碼。這就保證了所要保護物件的機密性。
註冊時:
- 1.使用者註冊，系統隨機產生salt值。
- 2.將salt值和密碼連線起來，生產Hash值。
- 3.將Hash值和salt值分別儲存在資料庫中。
登陸時:
- 1.系統根據使用者名稱找到與之對應的密碼Hash。
- 2.將使用者輸入密碼和salt值進行雜湊。
- 3.判斷生成的Hash值是否和資料庫中Hash相同。
PS:其實圖中的這種登入也是不安全的. 原因是後面要提到的鹽值複用
使用加鹽加密時需要注意以下兩點：
- 短鹽值（Short Slat）
如果鹽值太短，攻擊者可以預先製作針對所有可能的鹽值的查詢表。例如，如果鹽值只有三個 ASCII 字元，那麼只有 95x95x95=857,375 種可能性，加大了被攻擊的可能性。還有，不要使用可預測的鹽值，比如使用者名稱，因為針對某系統使用者名稱是唯一的且被經常用於其他服務。
- 鹽值複用（Salt Reuse）
在專案開發中，有時會遇到將鹽值寫死在程式裡或者只有第一次是隨機生成的，之後都會被重複使用，這種加鹽方法是不起作用的。以登入密碼為例，如果兩個使用者有相同的密碼，那麼他們就會有相同的雜湊值，攻擊者就可以使用反向查表法對每個雜湊值進行字典攻擊，使得該雜湊值更容易被破解。
所以正確的加鹽方法如下：
（1）鹽值應該使用加密的安全偽隨機數生成器（ Cryptographically Secure Pseudo-Random Number Generator，CSPRNG ）產生，比如 C 語言的 rand() 函式，這樣生成的隨機數高度隨機、完全不可預測；
（2）鹽值混入目標文字中，一起使用標準的加密函式進行加密；
（3）鹽值要足夠長（經驗表明：鹽值至少要跟雜湊函式的輸出一樣長）且永不重複；
（4）鹽值最好由服務端提供，前端取值使用。
慢雜湊函式（Slow Hash Function）
顧名思義，慢雜湊函式是將雜湊函式變得非常慢，使得攻擊方法也變得很慢，慢到足以令攻擊者放棄，而往往由此帶來的延遲也不會引起使用者的注意。降低攻擊效率用到了金鑰擴充套件（ key stretching）的技術，而金鑰擴充套件的實現使用了一種 CPU 密集型雜湊函式（ CPU-intensive hash function）。看起來有點暈~還是關注下該函式怎麼用吧！
如果想在一個 Web 應用中使用金鑰擴充套件，則需要設定較低的迭代次數來降低額外的計算成本。我們一般直接選擇使用標準的演算法來完成，比如 PBKDF2 或 bcrypt 。PHP、斯坦福大學的 JavaScript 加密庫都包含了 PBKDF2 的實現，瀏覽器中則可以考慮使用 JavaScript 完成，否則這部分工作應該由服務端進行計算。
金鑰雜湊
金鑰雜湊是將金鑰新增到雜湊加密，這樣只有知道金鑰的人才可以進行驗證。目前有兩種實現方式：使用 ASE 演算法對雜湊值加密、使用金鑰雜湊演算法 HMAC 將金鑰包含到雜湊字串中。為了保證金鑰的安全，需要將其儲存在外部系統（比如一個物理上隔離的服務端）。
即使選擇了金鑰雜湊，在其基礎上進行加鹽或者金鑰擴充套件處理也是很有必要。目前金鑰雜湊用於服務端比較多，例如來應對常見的 SQL 注入攻擊。
XOR
XOR 大家都不陌生，它指的是邏輯運算中的 “異或運算”。兩個值相同時，返回 false，否則返回 true，用來判斷兩個值是否不同。
JavaScript 語言的二進位制運算，有一個專門的 XOR 運算子，寫作^。
1 ^ 1 // 0 0 ^ 0 // 0 1 ^ 0 // 1 0 ^ 1 // 1 複製程式碼
XOR 運算有一個特性： 如果對一個值連續做兩次 XOR，會返回這個值本身。這也是其可以用於資訊加密的根本。
message XOR key // cipherText cipherText XOR key // message 複製程式碼
目標文字 message，key 是金鑰，第一次執行 XOR 會得到加密文字；在加密文字上再用 key 做一次 XOR 就會還原目標文字 message。為了保證 XOR 的安全，需要滿足以下兩點：
（1）key 的長度大於等於 message ；
（2）key 必須是一次性的，且每次都要隨機產生。
下面以登入密碼加密為例介紹下 XOR 的使用：
第一步：使用 MD5 演算法，計算密碼的雜湊；
const message = md5(password); 複製程式碼
第二步：生成一個隨機 key 值；
第三步：進行 XOR 運算，求出加密後的 message。
function getXOR(message, key)
const arr = [];
//假設 key 是32位的
for (let i = 0; i < 32; i++) {
constm = parseInt(message.substr(i, 1), 16);
const k = parseInt(key.substr(i, 1), 16);
arr.push((m ^ k).toString(16));
}
return arr.join('');
}
複製程式碼
如上所示，使用 XOR 和一次性的金鑰 key 對密碼進行加密處理，只要 key 沒有洩露，目標文字就不會被破解。
上面說了那麼多，問題就來了：我們應該使用什麼樣的雜湊演算法呢？
（1）選擇經過驗證的成熟演算法，如 PBKDF2 等 ；
（2）crypt 的安全版本；
（3）避免使用自己設計的加密演算法。
HMAC
對於HMAC演算法,我也不是太瞭解.看了幾篇文章,感覺和加鹽很像,就是salt換成後端隨機生成的(好像可以防止重放攻擊).然後再通過HMAC演算法,得到摘要.
關於HMAC演算法部分可以詳細看這篇文章,我是學渣,看了半天也不是太懂.=.=
大概過程如下:
- 1.客戶端發出登入請求
- 2.伺服器返回一個隨機值，在會話記錄中儲存這個隨機值
- 3.客戶端將該隨機值作為金鑰，使用者密碼進行 hmac 運算，遞交給伺服器
- 4.伺服器讀取資料庫中的使用者密碼，利用金鑰做和客戶端一樣的 hmac運算，然後與使用者傳送的結果比較，如果一致，則使用者身份合法。
好處:
- 與自定義的加salt演算法不同，Hmac演算法針對所有雜湊演算法都通用，無論是MD5還是SHA-1。採用Hmac替代我們自己的salt演算法，可以使程式演算法更標準化，也更安全。(摘自雪峰大佬的這篇文章)
- 另外一個就是密碼的安全性,由於不知道金鑰，所以不可能獲取到使用者密碼
補充1: 結合驗證碼進行前端加密(其實就是一種動態加鹽雜湊)
前端先將密碼雜湊，然後和使用者輸入的驗證碼進行雜湊，得到的結果作為密碼欄位傳送給伺服器。伺服器先確認驗證碼正確，然後再進行密碼驗證，否則直接返回驗證碼錯誤資訊。
這種實踐保證了密碼在傳輸過程中的資料安全，即使攻擊者拿到了資料也無法重放。圖形化驗證碼更是增加了難度。另一方面該實踐大大增加了撞庫的成本。
前端加密一定程度保障了傳輸過程中的資料安全，那麼會不會有對兩端（客戶端和伺服器）有安全幫助呢？
有幫助，使用一些前端加密手段，可以增加拖庫後的資料破解難度。但是驗證碼方法不具有這樣的功能，因為資料庫存的仍是明文密碼雜湊後的結果，那麼攻擊者可以繞過前端加密，可以直接暴力破解。
補充2: Base64 編碼
大家經常說的是 Base64 加密，有 Base64 加密嗎？ 真木有，只有 Base64 編碼。
Base64 是一種基於 64 個可列印字元來表示二進位制資料的表示方法。常用於在通常處理文字資料的場合，表示、傳輸、儲存一些二進位制資料,包括 MIME 的 email，email via MIME，在 XML 中儲存複雜資料；主要用來解決把不可列印的內容塞進可列印內容的需求。js中 base64 方法使用如下：
//1.編碼
var result = Base.encode('shotCat好帥!');//--> "c2hvdENhdOWlveW4hSE="
//2.解碼
var result2 = Base.decode(result); //--> 'shotCat好帥!' 沒錯,我就是這麼不要臉!!!
複製程式碼
因此，Base64 適用於小段內容的編碼，比如數字證書籤名、Cookie的內容等；而且 Base64 也是一種通過查表的編碼方法，不能用於加密，如果需要加密，請使用專業的加密演算法。
PS:對於前端來說,base64用得最多的也就是圖片轉碼吧.
補充3: 數字簽名
數字簽名主要用於: 確認資訊來源於特定的主體且資訊完整、未被篡改，傳送方生成簽名，接收方驗證簽名。
傳送方:首先計算目標文字的摘要（雜湊值），通過私鑰對摘要進行簽名，將目標文字和電子簽名傳送給接收方。
接收方:驗證簽名的步驟如下：
- 1,通過公鑰破解電子簽名，得到摘要 D1 (如果失敗，則資訊來源主體校驗失敗)；
- 2,計算目標文字摘要 D2；
- 3,若 D1 === D2，則說明目標文字完整、未被篡改。
數字簽名與非對稱加密區別:
- 非對稱加密（加密/解密）：公鑰加密，私鑰解密。
- 數字簽名（簽名/驗證）：私鑰簽名，公鑰驗證。