首頁»數據庫»為什么要在密碼里加點“鹽”

                    為什么要在密碼里加點“鹽”

                    來源:libuchao.com 發布時間:2017-08-26 閱讀次數:

                     鹽(Salt)

                      在密碼學中,是指通過在密碼任意固定位置插入特定的字符串,讓散列后的結果和使用原始密碼的散列結果不相符,這種過程稱之為“加鹽”。

                      以上這句話是維基百科上對于 Salt 的定義,但是僅憑這句話還是很難理解什么叫 Salt,以及它究竟起到什么作用。

                     

                     第一代密碼

                      早期的軟件系統或者互聯網應用,數據庫中設計用戶表的時候,大致是這樣的結構:

                    mysql> desc User;
                    +----------+--------------+------+-----+---------+-------+
                    | Field    | Type         | Null | Key | Default | Extra |
                    +----------+--------------+------+-----+---------+-------+
                    | UserName | varchar(50)  | NO   |     |         |       |
                    | PassWord | varchar(150) | NO   |     |         |       |
                    +----------+--------------+------+-----+---------+-------+
                    

                      數據存儲形式如下:

                    mysql> select * from User;
                    +----------+----------+
                    | UserName | PassWord |
                    +----------+----------+
                    | lichao   | 123      |
                    | akasuna  | 456      |
                    +----------+----------+
                    

                      主要的關鍵字段就是這么兩個,一個是登陸時的用戶名,對應的一個密碼,而且那個時候的用戶名是明文存儲的,如果你登陸時用戶名是 123,那么數據庫里存的就是 123。這種設計思路非常簡單,但是缺陷也非常明顯,數據庫一旦泄露,那么所有用戶名和密碼都會泄露,后果非常嚴重。參見 《CSDN 詳解 600 萬用戶密碼泄露始末》

                     第二代密碼

                      為了規避第一代密碼設計的缺陷,聰明的人在數據庫中不在存儲明文密碼,轉而存儲加密后的密碼,典型的加密算法是 MD5 和 SHA1,其數據表大致是這樣設計的:

                    mysql> desc User;
                    +----------+--------------+------+-----+---------+-------+
                    | Field    | Type         | Null | Key | Default | Extra |
                    +----------+--------------+------+-----+---------+-------+
                    | UserName | varchar(50)  | NO   |     |         |       |
                    | PwdHash  | char(32)     | NO   |     |         |       |
                    +----------+--------------+------+-----+---------+-------+
                    

                      數據存儲形式如下:

                    mysql> select * from User;
                    +----------+----------------------------------+
                    | UserName | PwdHash                          |
                    +----------+----------------------------------+
                    | lichao   | 202cb962ac59075b964b07152d234b70 |
                    | akasuna  | 250cf8b51c773f3f8dc8b4be867a9a02 |
                    +----------+----------------------------------+
                    

                      假如你設置的密碼是 123,那么數據庫中存儲的就是 202cb962ac59075b964b07152d234b70 或 40bd001563085fc35165329ea1ff5c5ecbdbbeef。當用戶登陸的時候,會把用戶輸入的密碼執行 MD5(或者 SHA1)后再和數據庫就行對比,判斷用戶身份是否合法,這種加密算法稱為散列。

                      嚴格地說,這種算法不能算是加密,因為理論上來說,它不能被解密。所以即使數據庫丟失了,但是由于數據庫里的密碼都是密文,根本無法判斷用戶的原始密碼,所以后果也不算太嚴重。

                     第三代密碼

                      本來第二代密碼設計方法已經很不錯了,只要你密碼設置得稍微復雜一點,就幾乎沒有被破解的可能性。但是如果你的密碼設置得不夠復雜,被破解出來的可能性還是比較大的。

                      好事者收集常用的密碼,然后對他們執行 MD5 或者 SHA1,然后做成一個數據量非常龐大的數據字典,然后對泄露的數據庫中的密碼就行對比,如果你的原始密碼很不幸的被包含在這個數據字典中,那么花不了多長時間就能把你的原始密碼匹配出來。這個數據字典很容易收集,CSDN 泄露的那 600w 個密碼,就是很好的原始素材。

                      于是,第三代密碼設計方法誕生,用戶表中多了一個字段:

                    mysql> desc User;
                    +----------+-------------+------+-----+---------+-------+
                    | Field    | Type        | Null | Key | Default | Extra |
                    +----------+-------------+------+-----+---------+-------+
                    | UserName | varchar(50) | NO   |     |         |       |
                    | Salt     | char(50)    | NO   |     |         |       |
                    | PwdHash  | char(32)    | NO   |     |         |       |
                    +----------+-------------+------+-----+---------+-------+
                    

                      數據存儲形式如下:

                    mysql> select * from User;
                    +----------+----------------------------+----------------------------------+
                    | UserName | Salt                       | PwdHash                          |
                    +----------+----------------------------+----------------------------------+
                    | lichao   | 1ck12b13k1jmjxrg1h0129h2lj | 6c22ef52be70e11b6f3bcf0f672c96ce |
                    | akasuna  | 1h029kh2lj11jmjxrg13k1c12b | 7128f587d88d6686974d6ef57c193628 |
                    +----------+----------------------------+----------------------------------+
                    

                      Salt 可以是任意字母、數字、或是字母或數字的組合,但必須是隨機產生的,每個用戶的 Salt 都不一樣,用戶注冊的時候,數據庫中存入的不是明文密碼,也不是簡單的對明文密碼進行散列,而是 MD5( 明文密碼 + Salt),也就是說:

                    MD5('123' + '1ck12b13k1jmjxrg1h0129h2lj') = '6c22ef52be70e11b6f3bcf0f672c96ce'
                    MD5('456' + '1h029kh2lj11jmjxrg13k1c12b') = '7128f587d88d6686974d6ef57c193628'
                    

                      當用戶登陸的時候,同樣用這種算法就行驗證。

                      由于加了 Salt,即便數據庫泄露了,但是由于密碼都是加了 Salt 之后的散列,壞人們的數據字典已經無法直接匹配,明文密碼被破解出來的概率也大大降低。

                      是不是加了 Salt 之后就絕對安全了呢?淡然沒有!壞人們還是可以他們數據字典中的密碼,加上我們泄露數據庫中的 Salt,然后散列,然后再匹配。但是由于我們的 Salt 是隨機產生的,假如我們的用戶數據表中有 30w 條數據,數據字典中有 600w 條數據,壞人們如果想要完全覆蓋的壞,他們加上 Salt 后再散列的數據字典數據量就應該是 300000* 6000000 = 1800000000000,一萬八千億啊,干壞事的成本太高了吧。但是如果只是想破解某個用戶的密碼的話,只需為這 600w 條數據加上 Salt,然后散列匹配。可見 Salt 雖然大大提高了安全系數,但也并非絕對安全。

                      實際項目中,Salt 不一定要加在最前面或最后面,也可以插在中間嘛,也可以分開插入,也可以倒序,程序設計時可以靈活調整,都可以使破解的難度指數級增長。

                      PS,文中所謂第一、二、三代密碼的稱呼,是我自己 YY 的。

                    QQ群:WEB開發者官方群(515171538),驗證消息:10000
                    微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
                    提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
                    網友評論(共0條評論) 正在載入評論......
                    理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
                    登錄會員中心
                    福彩试机号今天