最近有個(gè)虛擬練習項目，涉及到系統安全保障的設計，于是對安全保障這塊做了一些更深入的了解。發(fā)現了很多有趣的東西，開(kāi)闊了眼界。中間查了一些資料，于是我打算重新整理，用更加循序漸進(jìn)，大家都能懂的方式，說(shuō)一說(shuō)如何設計一個(gè)安全的系統。
首先來(lái)看看最近幾年比較著(zhù)名的拖庫撞庫后密碼泄露的事件：
2011年12月，國內最大的程序員社區 CSDN 遭拖庫，600萬(wàn)個(gè)賬戶(hù)信息泄露。
2014年3月，攜程旅行網(wǎng)的系統存技術(shù)漏洞，漏洞可能導致用戶(hù)的姓名、身份證號碼、銀行卡類(lèi)別、銀行卡卡號、銀行卡CVV碼以及銀行卡6位Bin泄露。
2014年5月，小米論壇涉及800萬(wàn)用戶(hù)信息遭泄露，信息包括用戶(hù)名、密碼、注冊IP、郵箱等。
2014年12月，12306遭撞庫攻擊，13萬(wàn)用戶(hù)信息泄露，包括用戶(hù)賬號、明文密碼、身份證、郵箱等敏感信息。
2015年10月，網(wǎng)易郵箱遭攻擊，近5億條用戶(hù)信息被泄露，包括用戶(hù)名、密碼、密碼保護信息、登陸IP以及用戶(hù)生日等多個(gè)原始信息。
除了密碼泄露事件，數據被物理刪除的事件也是發(fā)生：
2015年5月，攜程網(wǎng)及APP陷入癱瘓，數據庫遭物理刪除疑似離職員工報復。
這么多大公司大網(wǎng)站的系統都遭到攻擊，泄露用戶(hù)信息，更別說(shuō)其他小網(wǎng)站了。這些攻擊都可以從技術(shù)上來(lái)進(jìn)行防范的，但是我們看到即使是大公司，安全方面也是那么的薄弱。
防范的方法簡(jiǎn)單來(lái)說(shuō)數據從用戶(hù)鍵盤(pán)敲出的那一刻，到服務(wù)器后臺存儲都要保持正確的姿勢。比如：
用正確的姿勢保存密碼。
用正確的姿勢傳輸數據。
用正確的姿勢加密敏感信息。
用正確的姿勢對數據進(jìn)行備份和監控。
這一步非常重要，也比較復雜。用戶(hù)在瀏覽器里輸入密碼，傳輸到服務(wù)器端進(jìn)行驗證，服務(wù)端將之前保存的密碼信息和用戶(hù)的輸入進(jìn)行比對。
安全性最低的是在服務(wù)端明文保存用戶(hù)的密碼，一旦服務(wù)器被入侵，數據被拖走（拖庫），所有用戶(hù)的密碼都直接的暴露在外面。這是最初級的做法，毫無(wú)安全性可言。假如你在一個(gè)網(wǎng)站或論壇注冊了一個(gè)賬號，該網(wǎng)站自動(dòng)發(fā)了一封郵件告訴你注冊成功，里面明文寫(xiě)了你的密碼，趕緊把密碼改了然后再也不要訪(fǎng)問(wèn)這個(gè)網(wǎng)站。
既然不能明文保存密碼，那當然是加密保存了。耍個(gè)小聰明，比如把密碼的字母倒著(zhù)存，或者每個(gè)字母存后一個(gè)字母，或者進(jìn)行異或混淆處理，表面上密碼看上去已經(jīng)看不出來(lái)原始的密碼是什么了，但實(shí)際上這個(gè)和明文保存密碼并沒(méi)有本質(zhì)區別，因為黑客既然可以入侵你的服務(wù)器，自然可以拿到你的加密代碼，只要按你的算法進(jìn)行簡(jiǎn)單的解密就可以得到原始密碼。
在我還是一個(gè)初學(xué)者的時(shí)候，我已被告知不能用前兩種方式保存密碼，當時(shí)的主流方法是使用 md5 加密密碼。（年代久遠，現在已絕非主流了。） md5 是一種不可逆的加密方法，即密碼被 md5 加密后是無(wú)法解密出原始密碼的，驗證密碼是否正確的方法是將用戶(hù)輸入的密碼 md5 加密后于數據庫里保存的 md5 機密后的結果進(jìn)行比對。這樣，服務(wù)器端在不知道真實(shí)用戶(hù)密碼的情況下也能對用戶(hù)密碼進(jìn)行驗證了。
這是早期比較主流的做法，然而，這依然是非常不安全的。因為只要枚舉所有短密碼進(jìn)行 md5 加密，做成一個(gè)索引表，就能輕易的逆推出原始密碼。這種預先計算好的用于逆推加密散列函數的表就是“彩虹表”。隨著(zhù)“彩虹表”不斷變大，md5 的加密已經(jīng)變得非常的不安全。2015年10月網(wǎng)易郵箱的用戶(hù)密碼泄露也被懷疑只對密碼進(jìn)行了 md5 加密。
加鹽 hash 是指在加密密碼時(shí)，不只是對密碼進(jìn)行 hash ，而是對密碼進(jìn)行調油加醋，放點(diǎn)鹽（salt）再加密，一方面，由于你放的這點(diǎn)鹽，讓密碼本身更長(cháng)強度更高，彩虹表逆推的難度更大，也因你放的這點(diǎn)鹽，讓黑客進(jìn)行撞庫時(shí)運算量更大，破解的難度更高。
如何進(jìn)行加鹽就是一門(mén)很重要的學(xué)問(wèn)了。md5 是一種 hash 算法，以下就拿 md5 來(lái)舉例。假如密碼是 123456 ，md5 的結果如下：
上面例子里的 #g5Fv;0Dvk就是我們加的鹽。加完之后，密碼的強度更高了，彩虹表破解的難度加大了?；蛘哌M(jìn)行加鹽兩次 md5 ：
到這里，你一定會(huì )有疑問(wèn)，是不是把 md5 多做幾次，或者自定義一些組合的方式就更安全了。其實(shí)不是的，黑客既然能拿到數據庫里的數據，也很有可能拿到你的代碼。
一個(gè)健壯的、牢不可破的系統應該是：
即使被拿走了數據和所有的代碼，也沒(méi)辦法破解里面的數據。
這也是為什么大家不必實(shí)現自己的加密算法，而是使用公開(kāi)的加密算法的原因，比如：RSA、AES、DES 等等。既然無(wú)法保證加密代碼不被泄露，那就使用公開(kāi)的加密算法，只要保護好私鑰信息，就算你知道我的加密方式也沒(méi)有任何幫助。
大部分情況下，使用 md5(md5(password) + salt) 方式加密基本上已經(jīng)可以了：
其中，最關(guān)鍵的是 salt 從哪里來(lái)？ salt 該怎么設置才能安全。有幾個(gè)重要的點(diǎn)：
不要使用固定不變的 salt。
每個(gè)用戶(hù)的 salt 都需要不同。
salt 必須由服務(wù)端使用安全的隨機函數生成。
客戶(hù)端運算需要的 salt 需要從服務(wù)端動(dòng)態(tài)獲取。
客戶(hù)端加鹽 hash 的結果并不是最終服務(wù)端存盤(pán)的結果。
由于客戶(hù)端也需要執行加鹽 hash ，所以，salt 不能直接寫(xiě)在客戶(hù)端，而是應該動(dòng)態(tài)從服務(wù)端獲得。服務(wù)端生成隨機的 salt 時(shí)，必須使用安全的隨機函數，防止隨機數被預測。
各語(yǔ)言安全的隨機函數：
| 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 值動(dòng)態(tài)從服務(wù)端獲取，也有可能被中間人攔截獲取。同時(shí)，客戶(hù)端的加鹽 hash 的過(guò)程相當于是完全暴露的。一種更安全的做法是，客戶(hù)端使用 javascript 進(jìn)行加鹽 hash，把結果傳到服務(wù)器后，服務(wù)器對結果再進(jìn)行一次 加鹽 hash或者加密 hash（比如：HMAC） ，然后再和數據庫的結果進(jìn)行比對。
如果需要達到更高的安全等級，可以考慮：
1. 使用更安全的 hash 函數用來(lái)抵抗碰撞攻擊，比如：SHA256, SHA512, RipeMD, WHIRLPOOL。
兩個(gè)不同的內容 hash 的結果可能相同，攻擊者在不知道真實(shí)密碼的情況下，使用其他密碼進(jìn)行碰撞攻擊從而登錄系統。使用更安全的 hash 函數可以減少這種情況的發(fā)生。
2. 可以使用一種大量消耗 cpu 的 hash 算法對抗暴力破解，比如PBKDF2 或者 bcrypt。
暴力破解就是枚舉所有可能的密碼進(jìn)行嘗試驗證，使用大量消耗 cpu 的 hash 算法可以極大增加暴力破解的時(shí)間。
3. 比較加鹽 md5 結果時(shí)，使用時(shí)間恒定的比較函數。
在比較兩個(gè)字符串時(shí)，通常都一個(gè)字符一個(gè)字符進(jìn)行比較，如果某個(gè)字符不匹配就會(huì )立即返回。攻擊者可以根據驗證的時(shí)間長(cháng)短來(lái)判斷前幾位字符是否正確，然后逐步修正最終得到正確的結果。
因此，在比較 hash 時(shí)，使用時(shí)間恒定的比較函數，可以讓攻擊者摸不著(zhù)頭腦。比如下面這段代碼：
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; }異或（^）操作可以用來(lái)判斷兩個(gè)字符是否相等，比如：
0 XOR 0 = 0 1 XOR 1 = 0 0 XOR 1 = 1 1 XOR 0 = 1上面的函數枚舉每個(gè)字符進(jìn)行異或判斷，然后將所有的結果取或運算，得到最終的結果，比較的時(shí)間是恒定的。
4. salt 的值不要和最終 hash 的結果存在同一個(gè)數據庫。
SQL 注入是常見(jiàn)的攻擊手段，被注入后數據庫里的數據被暴露無(wú)遺。所以，應該將 salt 分開(kāi)存儲，存到別的機器的數據庫里，讓攻擊者拿不到 salt ，從而無(wú)法輕易破解信息。
5. 最終存儲的結果使用基于 key 的 hash 函數，比如 HMAC。 key 從外部安全性極高的專(zhuān)屬服務(wù)中獲得。
有了這層加固，即使數據被拖庫，攻擊者也無(wú)法從 hash 的結果逆推回原始密碼。因為使用了加密的 hash 函數?；?key 的 hash 函數只是進(jìn)行哈希運算時(shí)，除了傳入原始內容外，還需要傳入一個(gè)密鑰（key）。攻擊者沒(méi)有 key 幾乎不可能對數據進(jìn)行解密。
key 可以保存在極高安全性的通用的 key 管理系統，使用加密協(xié)議傳輸，對訪(fǎng)問(wèn)者進(jìn)行驗證，只允許特定的機器有權限訪(fǎng)問(wèn)。
使用 HTTP 協(xié)議傳輸數據時(shí)，數據都是明文傳輸的，數據從發(fā)出到服務(wù)器接收，中間可能被劫持，篡改。比如常見(jiàn)的 DNS 劫持，HTTP 劫持，中間人攻擊。
用正確的姿勢傳輸數據，目的就是為了保證傳輸的數據安全，簡(jiǎn)單歸納為兩點(diǎn)：
需要確保進(jìn)行通訊的服務(wù)端是官方的、正確的服務(wù)端，而不是跟一個(gè)假的服務(wù)端在通信。
確保信息在網(wǎng)絡(luò )上傳輸時(shí)是加密的，只有客戶(hù)端和服務(wù)端有能力對數據進(jìn)行解密。
確保信息在傳輸時(shí)不被篡改，或者數據被篡改時(shí)能立即發(fā)現。
《改變未來(lái)的九大算法》一書(shū)中提到了公鑰加密和數字簽名技術(shù)，這是進(jìn)行安全通信的基礎技術(shù)保障。這里涉及到了加密技術(shù)，先了解兩個(gè)最基礎的概念：
對稱(chēng)加密：加密和解密時(shí)使用的是同一個(gè)密鑰。
非對稱(chēng)加密：需要兩個(gè)密鑰來(lái)進(jìn)行加密和解密：公開(kāi)密鑰（public key，簡(jiǎn)稱(chēng)公鑰）和私有密鑰（private key，簡(jiǎn)稱(chēng)私鑰） ，公鑰加密的信息只有私鑰才能解開(kāi)，私鑰加密的信息只有公鑰才能解開(kāi)。
非對稱(chēng)加密是實(shí)現驗證服務(wù)端合法性的基礎，常見(jiàn)的加密算法有 RSA、ECC等 。服務(wù)端生成一對公鑰和私鑰，公鑰是公開(kāi)的所有人都知道，客戶(hù)端需要和服務(wù)端通信時(shí)，使用該公鑰進(jìn)行數據加密，由于只有真實(shí)合法的服務(wù)端才擁有對應的私鑰，所有只有真實(shí)的服務(wù)端才能解密該信息，然后返回數據給客戶(hù)端時(shí)，使用客戶(hù)端自己生成的公鑰進(jìn)行加密，這樣數據只有對應的客戶(hù)端才能理解。
使用 HTTPS 時(shí)，數字證書(shū)里包含了名稱(chēng)和公鑰信息，只要認證該證書(shū)是合法的，并且對方能理解用該公鑰加密的信息，就能確定是合法的服務(wù)端。
既然使用非對稱(chēng)加密的方式，可以保證雙方安全的通信，那是不是就一直使用非對稱(chēng)加密傳輸數據就行了？理論上是可以的，但是非對稱(chēng)加密的效率要比對稱(chēng)加密的效率低很多。通常的做法是，通過(guò)非對稱(chēng)加密的方法，協(xié)商出一個(gè)只有雙方知道的對稱(chēng)加密密鑰。
即使在不安全的通信環(huán)境下，也可以協(xié)商出一個(gè)只有雙方才知道的對稱(chēng)加密密鑰。在《改變未來(lái)的九大算法》一書(shū)里，有一個(gè)經(jīng)典的描述如何交互密鑰的例子（在所有溝通都是透明的情況下，如何協(xié)商出一個(gè)只有你和阿諾德才知道的顏料顏色。）：
ECDH就是基于上面原理設計的密鑰交換算法：
密鑰協(xié)商好后，雙方就可以使用該密鑰進(jìn)行加密傳輸了，比如使用 AES 、 DES。
由于 ECDH 密鑰交換協(xié)議不驗證公鑰發(fā)送者的身份，因此無(wú)法阻止中間人攻擊。如果監聽(tīng)者 Mallory 截獲了 Alice 的公鑰，就可以替換為他自己的公鑰，并將其發(fā)送給 Bob。Mallory 還可以截獲 Bob 的公鑰，替換為他自己的公鑰，并將其發(fā)送給 Alice。這樣，Mallory 就可以輕松地對 Alice 與 Bob 之間發(fā)送的任何消息進(jìn)行解密。他可以更改消息，用他自己的密鑰對消息重新加密，然后將消息發(fā)送給接收者。
解決方法是，Alice 和 Bob 可以在交換公鑰之前使用數字簽名對公鑰進(jìn)行簽名。
即使攻擊者不能解密傳輸的內容，但仍可以使用重放攻擊嘗試身份驗證或用于欺騙系統。重放攻擊是指攻擊者將數據包截取后，向目標主機重新發(fā)送一遍數據包。
防御重放攻擊的方法主要有：
使用時(shí)間戳。數據包在一定時(shí)間范圍內才是有效的。
使用遞增的序號。收到重復的數據包時(shí)可以輕易的發(fā)現。
使用提問(wèn)應答方式。收到數據包時(shí)可以判斷出來(lái)是否應答過(guò)。
HTTPS 正是使用了上述的原理，保證了通信的安全。所以，任何對安全有需求的系統都應該使用 HTTPS。如果是使用自有協(xié)議開(kāi)發(fā)，比如 APP 或游戲，應該使用上述的方法保障通信的安全。
我們都知道，用戶(hù)的密碼不能明文保存，而且要使用不可逆的加密算法，只保存最終的 hash 結果用來(lái)驗證是否正確。那用戶(hù)其他的敏感信息呢？比如身份證、銀行卡、信用卡等信息，該如何加密保存而不被泄露呢？
對于身份證信息，可以像密碼一樣只保存 hash 的結果，可以用于用戶(hù)輸入身份證號后進(jìn)行驗證。假如需要給用戶(hù)顯示身份證信息，只需要保存抹掉了幾位數字的身份證號。
假如你的系統涉及到支付，需要用戶(hù)的銀行卡，信用卡（卡號，CVV碼）等信息時(shí)，必須遵循 PCI DSS（第三方支付行業(yè)數據安全標準）標準。PCI DSS 是由 PCI 安全標準委員會(huì )的創(chuàng )始成員(visa、mastercard、American Express、Discover Financial Services、JCB等)制定，力在使國際上采用一致的數據安全措施，包括安全管理、策略、過(guò)程、網(wǎng)絡(luò )體系結構、軟件設計的要求的列表等，全面保障交易安全。
如果只是銀行卡，還需要遵循 ADSS（銀聯(lián)卡收單機構賬戶(hù)信息安全管理標準） 標準。
2014年3月攜程泄露用戶(hù)銀行卡信息就是因為沒(méi)有遵循 PCI DSS標準。
2015年5月的攜程數據被刪事件，就是數據備份沒(méi)有做好的例子。數據備份是為了防止由于硬盤(pán)損壞或人為破壞導致的數據丟失。主要措施有：磁盤(pán) raid，物理備份（磁帶庫），異地的邏輯備份。同時(shí)做好權限控制，并對訪(fǎng)問(wèn)記錄做好監控，及時(shí)發(fā)現問(wèn)題，保留現場(chǎng)證據。
本文總結了設計一個(gè)安全系統的基本原理和方法，并沒(méi)有舉出一個(gè)特定具體的方案，因為不同的系統對安全性的要求各有不同，設計者應該根據自身系統的特點(diǎn)進(jìn)行具體設計。比如加鹽 hash 的具體實(shí)施方法，salt 值如何構成等等。
本文所述內容如有不實(shí)之處或者有爭議的部分，歡迎交流指出。
常用的加密算法：
對稱(chēng)加密：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES。
非對稱(chēng)加密：RSA、ECC（橢圓曲線(xiàn)加密算法）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
Hash 算法：MD2、MD4、MD5、HAVAL、SHA-1、SHA256、SHA512、RipeMD、WHIRLPOOL、SHA3、HMAC
DES、3DES、AES 區別：
DES：1976年由美國聯(lián)邦政府的國家標準局頒布，密鑰為 56 位。
3DES：DES加密算法的一種模式，它使用3條56位的密鑰對數據進(jìn)行三次加密。
AES：高級加密標準，是下一代的加密算法標準，速度快，安全級別高，用來(lái)替代原先的DES。密鑰長(cháng)度可以是128，192或256比特。
聯(lián)系客服
