1. 程式人生 > >談談系統密碼儲存策略

談談系統密碼儲存策略

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