談談系統密碼儲存策略

最近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加密，生成密碼儲存到資料庫。

這是一篇非常基礎的文章，但是卻被很多的開發和產品忽略，風險總在一念之間。安全永遠是一個相對的概念，我們只能提升破解安全的成本，無法做到絕對的安全。