引子

最近有個虛擬練習專案，涉及到系統安全保障的設計，於是對安全保障這塊做了一些更深入的瞭解。發現了很多有趣的東西，開闊了眼界。中間查了一些資料，於是我打算重新整理，用更加循序漸進，大家都能懂的方式，說一說如何設計一個安全的系統。

著名的安全事件

首先來看看最近幾年比較著名的拖庫撞庫後密碼洩露的事件：

2011年12月，國內最大的程式設計師社群 CSDN 遭拖庫，600萬個賬戶資訊洩露。
2014年3月，攜程旅行網的系統存技術漏洞，漏洞可能導致使用者的姓名、身份證號碼、銀行卡類別、銀行卡卡號、銀行卡CVV碼以及銀行卡6位Bin洩露。
2014年5月，小米論壇涉及800萬用戶資訊遭洩露，資訊包括使用者名稱、密碼、註冊IP、郵箱等。
2014年12月，12306遭撞庫攻擊，13萬用戶資訊洩露，包括使用者賬號、明文密碼、身份證、郵箱等敏感資訊。
2015年10月，網易郵箱遭攻擊，近5億條使用者資訊被洩露，包括使用者名稱、密碼、密碼保護資訊、登陸IP以及使用者生日等多個原始資訊。
除了密碼洩露事件，資料被物理刪除的事件也是發生：

2015年5月，攜程網及APP陷入癱瘓，資料庫遭物理刪除疑似離職員工報復。

這麼多大公司大網站的系統都遭到攻擊，洩露使用者資訊，更別說其他小網站了。這些攻擊都可以從技術上來進行防範的，但是我們看到即使是大公司，安全方面也是那麼的薄弱。

防範方法

防範的方法簡單來說資料從使用者鍵盤敲出的那一刻，到伺服器後臺儲存都要保持正確的姿勢。比如：

用正確的姿勢儲存密碼。
用正確的姿勢傳輸資料。
用正確的姿勢加密敏感資訊。
用正確的姿勢對資料進行備份和監控。
用正確的姿勢儲存密碼

這一步非常重要，也比較複雜。使用者在瀏覽器裡輸入密碼，傳輸到伺服器端進行驗證，服務端將之前儲存的密碼資訊和使用者的輸入進行比對。

1. 低階錯誤：明文儲存密碼

安全性最低的是在服務端明文儲存使用者的密碼，一旦伺服器被入侵，資料被拖走（拖庫），所有使用者的密碼都直接的暴露在外面。這是最初級的做法，毫無安全性可言。假如你在一個網站或論壇註冊了一個賬號，該網站自動發了一封郵件告訴你註冊成功，裡面明文寫了你的密碼，趕緊把密碼改了然後再也不要訪問這個網站。

1. 低階錯誤：可逆加密密碼

既然不能明文儲存密碼，那當然是加密儲存了。耍個小聰明，比如把密碼的字母倒著存，或者每個字母存後一個字母，或者進行異或混淆處理，表面上密碼看上去已經看不出來原始的密碼是什麼了，但實際上這個和明文儲存密碼並沒有本質區別，因為黑客既然可以入侵你的伺服器，自然可以拿到你的加密程式碼，只要按你的演算法進行簡單的解密就可以得到原始密碼。

1. 錯誤方法：md5 加密密碼

在我還是一個初學者的時候，我已被告知不能用前兩種方式儲存密碼，當時的主流方法是使用 md5 加密密碼。（年代久遠，現在已絕非主流了。） md5 是一種不可逆的加密方法，即密碼被 md5 加密後是無法解密出原始密碼的，驗證密碼是否正確的方法是將使用者輸入的密碼 md5 加密後於資料庫裡儲存的 md5 機密後的結果進行比對。這樣，伺服器端在不知道真實使用者密碼的情況下也能對使用者密碼進行驗證了。

這是早期比較主流的做法，然而，這依然是非常不安全的。因為只要列舉所有短密碼進行 md5 加密，做成一個索引表，就能輕易的逆推出原始密碼。這種預先計算好的用於逆推加密雜湊函式的表就是“彩虹表”。隨著“彩虹表”不斷變大，md5 的加密已經變得非常的不安全。2015年10月網易郵箱的使用者密碼洩露也被懷疑只對密碼進行了 md5 加密。

1. 正確方法：加鹽 hash 儲存密碼

加鹽 hash 是指在加密密碼時，不只是對密碼進行 hash ，而是對密碼進行調油加醋，放點鹽（salt）再加密，一方面，由於你放的這點鹽，讓密碼本身更長強度更高，彩虹表逆推的難度更大，也因你放的這點鹽，讓黑客進行撞庫時運算量更大，破解的難度更高。

如何進行加鹽就是一門很重要的學問了。md5 是一種 hash 演算法，以下就拿 md5 來舉例。假如密碼是 123456 ，md5 的結果如下：

md5

像 123456 這樣的簡單密碼，是很容易被逆推出來的。但是假如我們往簡單密碼里加點鹽試試：

md5-salt

上面例子裡的 #g5Fv;0Dvk 就是我們加的鹽。加完之後，密碼的強度更高了，彩虹表破解的難度加大了。或者進行加鹽兩次 md5 ：

double-md5-salt

到這裡，你一定會有疑問，是不是把 md5 多做幾次，或者自定義一些組合的方式就更安全了。其實不是的，黑客既然能拿到資料庫裡的資料，也很有可能拿到你的程式碼。

一個健壯的、牢不可破的系統應該是：

即使被拿走了資料和所有的程式碼，也沒辦法破解裡面的資料。

這也是為什麼大家不必實現自己的加密演算法，而是使用公開的加密演算法的原因，比如：RSA、AES、DES 等等。既然無法保證加密程式碼不被洩露，那就使用公開的加密演算法，只要保護好私鑰資訊，就算你知道我的加密方式也沒有任何幫助。

大部分情況下，使用 md5(md5(password) + salt) 方式加密基本上已經可以了：

salt

其中，最關鍵的是 salt 從哪裡來？ salt 該怎麼設定才能安全。有幾個重要的點：

不要使用固定不變的 salt。
每個使用者的 salt 都需要不同。
salt 要保持一定的長度。
salt 必須由服務端使用安全的隨機函式生成。
客戶端運算需要的 salt 需要從服務端動態獲取。
客戶端加鹽 hash 的結果並不是最終服務端存檔的結果。
由於客戶端也需要執行加鹽 hash ，所以，salt 不能直接寫在客戶端，而是應該動態從服務端獲得。服務端生成隨機的 salt 時，必須使用安全的隨機函式，防止隨機數被預測。

各語言安全的隨機函式：

Platform CSPRNG
PHP mcrypt_create_iv, openssl_random_pseudo_bytes
Java java.security.SecureRandom
Dot NET (C#, VB) System.Security.Cryptography.RNGCryptoServiceProvider
Ruby SecureRandom
Python os.urandom
Perl Math::Random::Secure
C/C++ (Windows API) CryptGenRandom
Any language on GNU/Linux or Unix Read from /dev/random or /dev/urandom
就算 salt 值動態從服務端獲取，也有可能被中間人攔截獲取。同時，客戶端的加鹽 hash 的過程相當於是完全暴露的。一種更安全的做法是，客戶端使用 javascript 進行加鹽 hash，把結果傳到伺服器後，伺服器對結果再進行一次 加鹽 hash 或者 加密 hash（比如：HMAC） ，然後再和資料庫的結果進行比對。

如果需要達到更高的安全等級，可以考慮：

1. 使用更安全的 hash 函式用來抵抗碰撞攻擊，比如：SHA256, SHA512, RipeMD, WHIRLPOOL。

兩個不同的內容 hash 的結果可能相同，攻擊者在不知道真實密碼的情況下，使用其他密碼進行碰撞攻擊從而登入系統。使用更安全的 hash 函式可以減少這種情況的發生。

1. 可以使用一種大量消耗 cpu 的 hash 演算法對抗暴力破解，比如PBKDF2 或者 bcrypt。

暴力破解就是列舉所有可能的密碼進行嘗試驗證，使用大量消耗 cpu 的 hash 演算法可以極大增加暴力破解的時間。

1. 比較加鹽 md5 結果時，使用時間恆定的比較函式。

在比較兩個字串時，通常都一個字元一個字元進行比較，如果某個字元不匹配就會立即返回。攻擊者可以根據驗證的時間長短來判斷前幾位字元是否正確，然後逐步修正最終得到正確的結果。

因此，在比較 hash 時，使用時間恆定的比較函式，可以讓攻擊者摸不著頭腦。比如下面這段程式碼：

private static boolean slowEquals(byte[] a, byte[] b)
{
int diff = a.length ^ b.length;
for(int i = 0; i < a.length && i < b.length; i++)
diff |= a[i] ^ b[i];
return diff == 0;
}
異或（^{）操作可以用來判斷兩個字元是否相等，比如：}

0 XOR 0 = 0 1 XOR 1 = 0
0 XOR 1 = 1 1 XOR 0 = 1
上面的函式列舉每個字元進行異或判斷，然後將所有的結果取或運算，得到最終的結果，比較的時間是恆定的。

1. salt 的值不要和最終 hash 的結果存在同一個資料庫。

SQL 注入是常見的攻擊手段，被注入後資料庫裡的資料被暴露無遺。所以，應該將 salt 分開儲存，存到別的機器的資料庫裡，讓攻擊者拿不到 salt ，從而無法輕易破解資訊。

1. 最終儲存的結果使用基於 key 的 hash 函式，比如 HMAC。 key 從外部安全性極高的專屬服務中獲得。

有了這層加固，即使資料被拖庫，攻擊者也無法從 hash 的結果逆推回原始密碼。因為使用了加密的 hash 函式。基於 key 的 hash 函式只是進行雜湊運算時，除了傳入原始內容外，還需要傳入一個金鑰（key）。攻擊者沒有 key 幾乎不可能對資料進行解密。

key 可以儲存在極高安全性的通用的 key 管理系統，使用加密協議傳輸，對訪問者進行驗證，只允許特定的機器有許可權訪問。

用正確的姿勢傳輸資料

使用 HTTP 協議傳輸資料時，資料都是明文傳輸的，資料從發出到伺服器接收，中間可能被劫持，篡改。比如常見的 DNS 劫持，HTTP 劫持，中間人攻擊。

用正確的姿勢傳輸資料，目的就是為了保證傳輸的資料安全，簡單歸納為兩點：

需要確保進行通訊的服務端是官方的、正確的服務端，而不是跟一個假的服務端在通訊。
確保資訊在網路上傳輸時是加密的，只有客戶端和服務端有能力對資料進行解密。
確保資訊在傳輸時不被篡改，或者資料被篡改時能立即發現。
1. 驗證服務端的合法性

《改變未來的九大演算法》一書中提到了公鑰加密和數字簽名技術，這是進行安全通訊的基礎技術保障。這裡涉及到了加密技術，先了解兩個最基礎的概念：

對稱加密：加密和解密時使用的是同一個金鑰。
非對稱加密：需要兩個金鑰來進行加密和解密：公開金鑰（public key，簡稱公鑰）和私有金鑰（private key，簡稱私鑰） ，公鑰加密的資訊只有私鑰才能解開，私鑰加密的資訊只有公鑰才能解開。
非對稱加密是實現驗證服務端合法性的基礎，常見的加密演算法有 RSA 、 ECC 等 。服務端生成一對公鑰和私鑰，公鑰是公開的所有人都知道，客戶端需要和服務端通訊時，使用該公鑰進行資料加密，由於只有真實合法的服務端才擁有對應的私鑰，所有隻有真實的服務端才能解密該資訊，然後返回資料給客戶端時，使用客戶端自己生成的公鑰進行加密，這樣資料只有對應的客戶端才能理解。

rsa

使用 HTTPS 時，數字證書裡包含了名稱和公鑰資訊，只要認證該證書是合法的，並且對方能理解用該公鑰加密的資訊，就能確定是合法的服務端。

1. 確保通訊的安全

既然使用非對稱加密的方式，可以保證雙方安全的通訊，那是不是就一直使用非對稱加密傳輸資料就行了？理論上是可以的，但是非對稱加密的效率要比對稱加密的效率低很多。通常的做法是，通過非對稱加密的方法，協商出一個只有雙方知道的對稱加密金鑰。

即使在不安全的通訊環境下，也可以協商出一個只有雙方才知道的對稱加密金鑰。在《改變未來的九大演算法》一書裡，有一個經典的描述如何互動金鑰的例子（在所有溝通都是透明的情況下，如何協商出一個只有你和阿諾德才知道的顏料顏色。）：

sharedkey

ECDH 就是基於上面原理設計的金鑰交換演算法：

ecdh

金鑰協商好後，雙方就可以使用該金鑰進行加密傳輸了，比如使用 AES 、 DES。

由於 ECDH 金鑰交換協議不驗證公鑰傳送者的身份，因此無法阻止中間人攻擊。如果監聽者 Mallory 截獲了 Alice 的公鑰，就可以替換為他自己的公鑰，並將其傳送給 Bob。Mallory 還可以截獲 Bob 的公鑰，替換為他自己的公鑰，並將其傳送給 Alice。這樣，Mallory 就可以輕鬆地對 Alice 與 Bob 之間傳送的任何訊息進行解密。他可以更改訊息，用他自己的金鑰對訊息重新加密，然後將訊息傳送給接收者。

解決方法是，Alice 和 Bob 可以在交換公鑰之前使用數字簽名對公鑰進行簽名。

即使攻擊者不能解密傳輸的內容，但仍可以使用重放攻擊嘗試身份驗證或用於欺騙系統。重放攻擊是指攻擊者將資料包擷取後，向目標主機重新發送一遍資料包。

防禦重放攻擊的方法主要有：

使用時間戳。資料包在一定時間範圍內才是有效的。
使用遞增的序號。收到重複的資料包時可以輕易的發現。
使用提問應答方式。收到資料包時可以判斷出來是否應答過。
HTTPS 正是使用了上述的原理，保證了通訊的安全。所以，任何對安全有需求的系統都應該使用 HTTPS。如果是使用自有協議開發，比如 APP 或遊戲，應該使用上述的方法保障通訊的安全。

用正確的姿勢加密敏感資訊

我們都知道，使用者的密碼不能明文儲存，而且要使用不可逆的加密演算法，只儲存最終的 hash 結果用來驗證是否正確。那使用者其他的敏感資訊呢？比如身份證、銀行卡、信用卡等資訊，該如何加密儲存而不被洩露呢？

對於身份證資訊，可以像密碼一樣只儲存 hash 的結果，可以用於使用者輸入身份證號後進行驗證。假如需要給使用者顯示身份證資訊，只需要儲存抹掉了幾位數字的身份證號。

假如你的系統涉及到支付，需要使用者的銀行卡，信用卡（卡號，CVV碼）等資訊時，必須遵循 PCI DSS （第三方支付行業資料安全標準）標準。PCI DSS 是由 PCI 安全標準委員會的創始成員(visa、mastercard、American Express、Discover Financial Services、JCB等)制定，力在使國際上採用一致的資料安全措施，包括安全管理、策略、過程、網路體系結構、軟體設計的要求的列表等，全面保障交易安全。

如果只是銀行卡，還需要遵循 ADSS （銀聯卡收單機構賬戶資訊保安管理標準） 標準。

2014年3月攜程洩露使用者銀行卡資訊就是因為沒有遵循 PCI DSS 標準。

用正確的姿勢對資料進行備份和監控

2015年5月的攜程資料被刪事件，就是資料備份沒有做好的例子。資料備份是為了防止由於硬碟損壞或人為破壞導致的資料丟失。主要措施有：磁碟 raid，物理備份（磁帶庫），異地的邏輯備份。同時做好許可權控制，並對訪問記錄做好監控，及時發現問題，保留現場證據。

總結
本文總結了設計一個安全系統的基本原理和方法，並沒有舉出一個特定具體的方案，因為不同的系統對安全性的要求各有不同，設計者應該根據自身系統的特點進行具體設計。比如加鹽 hash 的具體實施方法，salt 值如何構成等等。

本文所述內容如有不實之處或者有爭議的部分，歡迎交流指出。

附錄

常用的加密演算法：

對稱加密：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES。
非對稱加密：RSA、ECC（橢圓曲線加密演算法）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
Hash 演算法：MD2、MD4、MD5、HAVAL、SHA-1、SHA256、SHA512、RipeMD、WHIRLPOOL、SHA3、HMAC
DES、3DES、AES 區別：

DES：1976年由美國聯邦政府的國家標準局頒佈，金鑰為 56 位。
3DES：DES加密演算法的一種模式，它使用3條56位的金鑰對資料進行三次加密。
AES：高階加密標準，是下一代的加密演算法標準，速度快，安全級別高，用來替代原先的DES。金鑰長度可以是128，192或256位元。
參考文章

Salted Password Hashing - Doing it Right
ECDH 演算法概述
Rainbow table
《改變未來的九大演算法》第四章：公鑰加密