網站中很多涉及到系統安全保障的設計，那么，如何設計網站安全賬號系統呢?

我們先來看下一些著名的安全事件吧：

2011年12月，國內大的程序員社區(qū) CSDN 遭拖庫，600萬個賬戶信息泄露。

2014年3月，攜程旅行網的系統存技術漏洞，漏洞可能導致用戶的姓名、身份證號碼、銀行卡類別、銀行卡卡號、銀行卡CVV碼以及銀行卡6位Bin泄露。

2014年5月，小米論壇涉及800萬用戶信息遭泄露，信息包括用戶名、密碼、注冊IP、郵箱等。 2014年12月，12306遭撞庫攻擊，13萬用戶信息泄露，包括用戶賬號、明文密碼、身份證、郵箱等敏感信息。

2015年10月，網易郵箱遭攻擊，近5億條用戶信息被泄露，包括用戶名、密碼、密碼保護信息、登陸IP以及用戶生日等多個原始信息。

除了密碼泄露事件，數據被物理刪除的事件也是發(fā)生：

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

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

防范方法

防范的方法簡單來說數據從用戶鍵盤敲出的那一刻，到服務器后臺存儲都要保持正確的姿勢。比如：

用正確的姿勢保存密碼。 用正確的姿勢傳輸數據。 用正確的姿勢加密敏感信息。 用正確的姿勢對數據進行備份和監(jiān)控。 用正確的姿勢保存密碼

這一步非常重要，也比較復雜。用戶在瀏覽器里輸入密碼，傳輸到服務器端進行驗證，服務端將之前保存的密碼信息和用戶的輸入進行比對。

1. 低級錯誤：明文保存密碼

安全性最低的是在服務端明文保存用戶的密碼，一旦服務器被入侵，數據被拖走(拖庫)，所有用戶的密碼都直接的暴露在外面。這是最初級的做法，毫無安全性可言。假如你在一個網站或論壇注冊了一個賬號，該網站自動發(fā)了一封郵件告訴你注冊成功，里面明文寫了你的密碼，趕緊把密碼改了然后再也不要訪問這個網站。

2. 低級錯誤：可逆加密密碼

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

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

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

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

4. 正確方法：加鹽 hash 保存密碼

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

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

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

上面例子里的 #g5Fv;0Dvk 就是我們加的鹽。加完之后，密碼的強度更高了，彩虹表破解的難度加大了?；蛘哌M行加鹽兩次 md5 ：

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

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

即使被拿走了數據和所有的代碼，也沒辦法破解里面的數據。

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

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

其中，最關鍵的是 salt 從哪里來? salt 該怎么設置才能安全。

有幾個重要的點：

不要使用固定不變的 salt。 每個用戶的 salt 都需要不同。 salt 必須由服務端使用安全的隨機函數生成。 客戶端運算需要的 salt 需要從服務端動態(tài)獲取。 客戶端加鹽 hash 的結果并不是最終服務端存盤的結果。

由于客戶端也需要執(zhí)行加鹽 hash ，所以，salt 不能直接寫在客戶端，而是應該動態(tài)從服務端獲得。服務端生成隨機的 salt 時，必須使用安全的隨機函數，防止隨機數被預測。

各語言安全的隨機函數：

就算 salt 值動態(tài)從服務端獲取，也有可能被中間人攔截獲取。同時，客戶端的加鹽 hash 的過程相當于是完全暴露的。一種更安全的做法是，客戶端使用 javascript 進行加鹽 hash，把結果傳到服務器后，服務器對結果再進行一次 加鹽 hash 或者 加密 hash(比如：HMAC) ，然后再和數據庫的結果進行比對。

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

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

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

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

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

3. 比較加鹽 md5 結果時，使用時間恒定的比較函數。

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

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

異或(^)操作可以用來判斷兩個字符是否相等，比如：

上面的函數枚舉每個字符進行異或判斷，然后將所有的結果取或運算，得到最終的結果，比較的時間是恒定的。

4. salt 的值不要和最終 hash 的結果存在同一個數據庫。

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

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

有了這層加固，即使數據被拖庫，攻擊者也無法從 hash 的結果逆推回原始密碼。因為使用了加密的 hash 函數?；?key 的 hash 函數只是進行哈希運算時，除了傳入原始內容外，還需要傳入一個密鑰(key)。攻擊者沒有 key 幾乎不可能對數據進行解密。

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

用正確的姿勢傳輸數據

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

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

需要確保進行通訊的服務端是官方的、正確的服務端，而不是跟一個假的服務端在通信。 確保信息在網絡上傳輸時是加密的，只有客戶端和服務端有能力對數據進行解密。 確保信息在傳輸時不被篡改，或者數據被篡改時能立即發(fā)現。

1. 驗證服務端的合法性

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

對稱加密：加密和解密時使用的是同一個密鑰。 非對稱加密：需要兩個密鑰來進行加密和解密：公開密鑰(public key，簡稱公鑰)和私有密鑰(private key，簡稱私鑰) ，公鑰加密的信息只有私鑰才能解開，私鑰加密的信息只有公鑰才能解開。

非對稱加密是實現驗證服務端合法性的基礎，常見的加密算法有 RSA 、 ECC 等 。服務端生成一對公鑰和私鑰，公鑰是公開的所有人都知道，客戶端需要和服務端通信時，使用該公鑰進行數據加密，由于只有真實合法的服務端才擁有對應的私鑰，所有只有真實的服務端才能解密該信息，然后返回數據給客戶端時，使用客戶端自己生成的公鑰進行加密，這樣數據只有對應的客戶端才能理解。

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

2. 確保通信的安全

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

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

ECDH 就是基于上面原理設計的密鑰交換算法：

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

由于 ECDH 密鑰交換協議不驗證公鑰發(fā)送者的身份，因此無法阻止中間人攻擊。如果監(jiān)聽者 Mallory 截獲了 Alice 的公鑰，就可以替換為他自己的公鑰，并將其發(fā)送給 Bob。Mallory 還可以截獲 Bob 的公鑰，替換為他自己的公鑰，并將其發(fā)送給 Alice。這樣，Mallory 就可以輕松地對 Alice 與 Bob 之間發(fā)送的任何消息進行解密。他可以更改消息，用他自己的密鑰對消息重新加密，然后將消息發(fā)送給接收者。

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

即使攻擊者不能解密傳輸的內容，但仍可以使用重放攻擊嘗試身份驗證或用于欺騙系統。重放攻擊是指攻擊者將數據包截取后，向目標主機重新發(fā)送一遍數據包。

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

使用時間戳。數據包在一定時間范圍內才是有效的。 使用遞增的序號。收到重復的數據包時可以輕易的發(fā)現。 使用提問應答方式。收到數據包時可以判斷出來是否應答過。

HTTPS 正是使用了上述的原理，保證了網站安全維護。所以，任何對安全有需求的系統都應該使用 HTTPS。如果是使用自有協議開發(fā)，比如 APP 或游戲，應該使用上述的方法保障通信的安全。

用正確的姿勢加密敏感信息

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

對于身份證信息，可以像密碼一樣只保存 hash 的結果，可以用于用戶輸入身份證號后進行驗證。假如需要給用戶顯示身份證信息，只需要保存抹掉了幾位數字的身份證號。

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

如果只是銀行卡，還需要遵循 ADSS (銀聯卡收單機構賬戶信息安全管理標準) 標準。

2014年3月攜程泄露用戶銀行卡信息就是因為沒有遵循 PCI DSS 標準。

用正確的姿勢對數據進行備份和監(jiān)控

2015年5月的攜程數據被刪事件，就是數據備份沒有做好的例子。數據備份是為了防止由于硬盤損壞或人為破壞導致的數據丟失。主要措施有：磁盤 raid，物理備份(磁帶庫)，異地的邏輯備份。同時做好權限控制，并對訪問記錄做好監(jiān)控，及時發(fā)現問題，保留現場證據。

總結

本文總結了設計一個安全系統的基本原理和方法，并沒有舉出一個特定具體的方案，因為不同的系統對安全性的要求各有不同，設計者應該根據自身系統的特點進行具體設計。比如加鹽 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 區(qū)別：

DES：1976年由美國聯邦政府的國家標準局頒布，密鑰為 56 位。

3DES：DES加密算法的一種模式，它使用3條56位的密鑰對數據進行三次加密。

AES：高級加密標準，是下一代的加密算法標準，速度快，安全級別高，用來替代原先的DES。密鑰長度可以是128，192或256比特。

文章題目：建站教程：如何設計網站安全賬號系統
標題來源：http://www.rwnh.cn/news32/159982.html

成都網站建設公司_創(chuàng)新互聯，為您提供面包屑導航、做網站、微信公眾號、建站公司、手機網站建設、搜索引擎優(yōu)化

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯