最近IT界很火的一則新聞是華住的數據庫泄露問題，身邊很多人在討論數據庫安全的問題，大家經常說提升密碼復雜度、加密等，但是很多人並不知道在開發的時候，用戶的密碼怎么處理，或者說，處理的並不恰當，這篇文章主要介紹在系統設計的過程中，我們的密碼究竟應該怎么處理才最大限度的保證安全。
密碼加密的重要性？
還是從脫庫說起，數據庫被人拉走了，最可怕的是什么？個人手機、身份證、地址？？這些是很重要，但是，其實個人隱私數據，獲取的難度不是很大，而且不容易直接對一個人造成巨大的傷害，但是，密碼被人知道了，就是很可怕的事情。因為，大部分人不同的系統都是共用密碼。這個錯誤比較低級，但是很常見，所以，密碼，是被脫庫后最容易被人利用。所以，密碼是必須加密的，不把用戶密碼加密的系統和公司，都該判刑。
密碼管理的入門要求
密碼管理產品級別的需求，大家都能看到的是，提升密碼的復雜度和管理策略，一般包括：
- 密碼加密保存，並且是不可逆的。
- 密碼更長更復雜。如：密碼長度大於8位，必須是大小寫字母和數字的組合。
- 定期修改密碼策略。
- 登錄輸入密碼錯誤多次，需要輸入驗證碼，甚至是鎖定賬戶。
以上都是一些基礎，但是非常有效的方案，這些產品設計不是我們討論的重點，我們重點說說具體的實現。
在技術上， 實際密碼我們是怎么存儲的呢？
String password=MD5("明文")
對用戶的輸入進行MD5加密后，就直接保存在數據庫，可能15年前這還是比較安全的存儲方式，但是現在，MD5已經不再安全，越是簡單的密碼，被撞庫獲取到原文的可能性非常的高，所以直接使用MD5加密后保存密碼，顯然已經是非常不安全的方式了。
密碼+salt
前文說道，密碼太短，顯然已經不安全了，那么為了提升負責度，就會強制把用戶的密碼變得更加復雜，於是，就產生了密碼加salt的方案。salt肯定是需要一個比較的復雜的字符串，長度可以長一點。而且最好是，每個用戶的salt是不一樣的。以前的數據庫結構是：
| ID | 用戶名 | 密碼 |
|---|---|---|
| 1 | user1 | 34234sdfse2342dggs234s |
| 2 | user2 | d34desf3432sdf23423sdf |
那么比較安全的方式應該是：
| ID | 用戶名 | 密碼 | salt |
|---|---|---|---|
| 1 | user1 | sdf452342sdfsd23234sdf | 982934&7934708hHG12&%&()()()IUHUHGggifiknsdf |
| 2 | user2 | 234df3234sdf234asfddsd | &&8uhhhkKHKl9(7KBKH&……)adksjknklasdlfkjkkkkk |
String password=SHA1("明文"+salt);
這里，我們用了相對而言撞庫難度比較大的SHA1的加密方式來取代MD5加密，這樣基本就是一個比較安全的密碼了，即使數據被脫庫了，撞庫也很基本不可能破解出明文。
但是，這樣就真的安全了嗎？不一定，我們還少了傳輸加密以及客戶端加密。
客戶端和傳輸加密
首先我們說說傳輸加密，其實，這個現在已經有很標准的解決方案——https，這里我們就不多說了。
我們主要所屬說說客戶端加密：
可能大家覺得有了傳輸加密了，實際客戶端加密也不太重要，顯然不是，這里有個很重要的場景就容易出現風險：
- 日志。大家的系統都會統一記錄日志，針對密碼這類敏感的信息，如果記錄了日志，而且大家記錄的都是用戶輸入的明文，這樣非常危險。
- 內網劫持。如果數據還沒有到公網，在內網就被劫持了，有可能暴露明文的密碼。
所以，客戶端加密也是很有必要的。現在的前端技術都是支持MD5加密，所以我們就在前端對用戶的數據進行了MD5加密。
客戶端代碼：
var password=md5("明文");
String password=SHA1("客戶端MD5加密后的支付"+salt);
實際，這樣最終存在數據庫的，就是一個做了雙重加密的支付。網絡傳輸和日志記錄的就是單次加密的字符，整體的安全度就非常高了。
總結
這樣，一個好的密碼體系應該就是這樣了：
- 客戶端MD5針對用戶輸入的明文加密后提交到服務端。
- 服務端根據用戶生成一個復雜的隨機salt。
- 根據隨機salt和接收到的密碼，sha1加密，生成密碼保存到數據庫。
這是一篇非常基礎的文章，但是卻被很多的開發和產品忽略，風險總在一念之間。安全永遠是一個相對的概念，我們只能提升破解安全的成本，無法做到絕對的安全。
歡迎大家關注我的公眾號交流、學習、第一時間獲取最新的文章。
微信號：itmifen
