談談系統密碼存儲策略

最近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