昨天午休時，新浪上的一條新聞引起了我的注意。新聞中說，一家叫芝麻金融的P2P網站資料庫洩露，並且資料庫中所記錄的密碼僅經過一次雜湊。雖然說我不是攻破它的白帽，更沒有仔細地研究這些洩露的資料，但如果報告所言不虛，其中所提及的各個問題實際上非常嚴重。因此我覺得有必要對如何在系統中儲存密碼以及為什麼要這樣做進行一個簡單的介紹。

　　在這篇文章中，我會簡單地介紹一下當前比較流行的對密碼進行攻擊的手段，從而讓大家瞭解我們平常所自認為“安全”的密碼保護手段實際上在黑客面前不堪一擊。進而我也會介紹這些攻擊的防範手段，以及業內較為認同的密碼儲存方法，進而使大家做出的網站能夠更安全地儲存使用者的密碼。

一場曠日持久的戰爭

　　記得我最早接觸網路的時候大概是1999年的秋天，那年我初三。初三對於我來說有兩個事情要去做：準備中考，更要準備考全國理科實驗班。為了儲存所有我在網上找到的競賽試卷，我申請了第一個郵箱，而郵箱的密碼只有4個字母。在那之後，各種密碼丟失的事件逐漸多了起來，例如騰迅QQ被盜，個人郵箱被盜等。因此在03年左右，那個網站就開始對密碼的長度有了強制的要求。原因很簡單：為了防止暴力破解。

　　而後又出現了更多更為高明的方法，例如XSS，CSRF，Session Fixation等等。而相應的安全方法也逐漸地進行著改進，如HttpOnly Cookie，HTTP請求中新增的Referer頭等。這一系列攻防所圍繞的正是使用者的身份憑證，如Session ID，使用者的密碼。因為有了它們，黑客就可以偽裝成合法使用者來悄悄地執行一系列非法行為，從而獲得利益。

　　因此如何安全地保護使用者的身份憑證實際上是各個網站最需要關注的問題。在使用身份憑證的任何地方，我們都需要提供對身份憑證的保護，如使用者輸入密碼時，使用者在登陸以後對網站的操作，身份憑證在網路上的傳輸，以及密碼在資料庫中的儲存等等。而在這些場景中，對身份憑證進行保護的方法也不盡相同。

　　在使用者輸入密碼的時候，黑客可以通過偵聽使用者輸入來完成使用者名稱/密碼對的竊取。在使用者登入以後，如果Cookie中記錄了使用者名稱/密碼對，那麼惡意人員也可以通過XSS（祥見我另一篇部落格），CSRF等方式進行攻擊。而身份憑證在網路上傳輸的時候，惡意人員可以通過中間人方式來竊取使用者的身份憑證。可以看到，為了保證使用者身份憑證的安全，一個網站需要在不同的維度對使用者的身份憑證進行保護。

　　而密碼在資料庫中正確地儲存對於整個網站而言更為重要。一般來說，網站都會對盡一切可能保護自己的資料庫，以防止私密資訊洩露或資料被惡意更改。但是一旦這些防禦手段失效，那麼資料庫中記錄的使用者名稱/密碼資訊將會直接暴露在惡意使用者眼中。因此我們要對這些密碼加密，以構築保護使用者身份憑證的最後一道防線。這道防線尤為重要。因為一旦該密碼加密方法被攻破，那麼黑客所得到的使用者名稱/密碼對都有可能被攻破。對於該網站而言，這會允許非法使用者使用這些被攻破的使用者名稱/密碼對執行非法操作，如虛假交易，帳戶資金轉移等。而就使用者而言，由於絕大部分使用者都習慣於在多個網站中使用同一套使用者名稱/密碼對，因此在一個網站中身份憑證的洩露極有可能危及到他在其它網站中的身份憑證，從而導致他在多個網站中的賬號同時被盜。因此即使是我們的網站私密性要求不高，我們也一樣需要妥當地儲存使用者所設定的密碼。

不安全的密碼儲存方式

　　最不安全的密碼儲存方式就是使用明文在資料庫中儲存密碼。我們最可愛的CSDN就幹過這事。明文密碼的意思就是並沒有經過任何處理就將使用者帳戶所對應的密碼記錄在了資料庫中。這樣做最起碼有一個不好的地方，那就是如果一個人擁有資料庫訪問許可權，那麼他可以很輕易地看到使用者名稱和其所對應的密碼。從安全的角度來說，這種密碼儲存方式是不被信任的，因為誰也無法保證擁有資料庫訪問許可權的人不會為了利益主動洩露這些使用者名稱/密碼對。

　　就算是資料庫管理員可以被信任，這些密碼也可能因為資料庫管理員無意中的一個過失而洩露。例如在資料庫管理員檢視資料庫的時候離開電腦去喝杯水，卻沒有在離開時鎖定電腦，那麼其他人就可以檢視資料庫表來得到一系列的使用者名稱/密碼對。

　　當然事情可以變得更為糟糕：如果網站上存在著SQL注入漏洞，那麼黑客就可能通過SQL注入等攻擊手段來得到資料庫中使用者名稱和密碼列中所記錄的資料。如果這些資料並沒有經過處理，那麼惡意使用者就將直接得到該使用者名稱所對應的密碼。

　　那麼我們應該如何記錄這些密碼呢？相信讀者很容易就想到計算它們的雜湊值。是的，這也是當前業內所最常使用的手段。那麼是不是我們隨便選擇一個雜湊演算法就可以了呢？答案是否定的。這是因為現在已經出現了很多針對雜湊計算結果的攻擊方法。

　　簡單地想象下面的一個情況，那就是網站有SQL注入漏洞。那麼惡意攻擊者非常有可能通過該SQL注入漏洞來獲得一系列使用者名稱和簡單雜湊演算法所加密過的密碼。這些資料可能有上萬個，甚至有百萬條之多。現在他所知道的僅僅是密碼經過雜湊後的結果，而雜湊過程中所使用的雜湊演算法以及輸入他並不瞭解。

　　接下來，他要做的工作就是列出一系列可能的加密演算法以及一系列最常用的密碼。這裡你需要相信的是，你所能想到的雜湊演算法一個有經驗的黑客絕對能夠想到。而常用的密碼，上網上搜索“最常用的密碼”，或者找一本密碼字典就足夠了。在一個包含了上萬使用者的網站中，有接近百分之百的機率出現形如“12345qwer”這樣的密碼。

　　OK，現在他的工作開始了：從密碼字典中選擇一個最常用的密碼，並通過他所蒐集到的雜湊演算法分別進行加密。接下來，將這些加密結果與他剛剛所得到的那些雜湊過的密碼進行比較。該過程中，一次雜湊計算所得到的結果可以與其所得到的多個密碼的雜湊值同時進行比較。在樣本數目非常大的情況下，該結果的命中概率將變得非常大。這就是攻擊者在執行攻擊時的一個非常大的優勢：基於極多的樣本並行地執行攻擊嘗試。

　　一旦一個雜湊演算法所得到的結果和任意一個密碼的雜湊值匹配成功，那麼當前所使用的加密演算法就非常有可能是系統所使用的加密演算法。在使用不同的常用密碼多次嘗試以後，你所使用的加密演算法在黑客眼中就已經非常明顯了。如果這個加密演算法是雙向的，那麼可以說，這個被攻擊的系統已經完全淪陷了。

　　而這種攻擊甚至可以被加速：在嘗試猜測加密演算法之前，該惡意使用者會首先對這些常用的演算法以及常用密碼計算對應的雜湊值，並直接使用這些雜湊值與所得到的雜湊過的密碼進行比較。這甚至省略了計算雜湊的時間，並使得這些雜湊計算結果可以被重用。這種攻擊有一個特殊的名字：Rainbow Table Attack。

展開防禦

　　是不是覺得有點恐怖？不用擔心，有攻擊就有防禦。攻防之間的鬥智鬥勇才是安全領域最有意思的事情。

　　現在我們來想想這種攻擊成功的必要條件：一個黑客能夠猜中的加密演算法，和一個黑客同樣能夠猜中的密碼。這兩個必要條件都是基於概率的：黑客猜中加密演算法的概率較高，而且在使用者數目較大的情況下，系統中存在形如“12345qwer”的密碼的概率非常大。而要想阻止黑客攻擊，我們就需要讓我們的網站不再具有這種必要條件。

　　對於第一個必要條件，我們的解決方案並不是要自創一個新的加密演算法。這從安全的角度來說是完全不安全的。在後面的章節中我們會對這種做法為什麼不安全進行講解。而我們所需要的解決方案則是讓黑客猜不中我們所使用的加密演算法，也就是使用多種加密演算法進行加密。這樣即使是同樣的密碼也會產生不同的結果，減小黑客猜中雜湊演算法的概率。而對於第二個必要條件，我們則可以對密碼本身進行一次增強。該增強演算法需要儘量增加密碼本身的複雜度卻基本不產生密碼碰撞（即增加了複雜度的兩個密碼最終變成了一樣的密碼）。這樣即使黑客猜對了增強後的密碼以及對其加密所使用的演算法，那麼他也無法知道原始密碼到底是什麼樣子的。而這一步，業內的建議也是要由標準類庫來完成。這其中的顧慮實際上與不要自創加密演算法一樣。

　　那麼黑客就剩下一個攻擊方法了，那就是硬猜，也就是常說的暴力破解（Brute Force Attack）。一個一個地猜雖然是一個笨方法，但是隨著猜測次數的增加，猜中密碼的概率也會逐漸增大。為了避免這種攻擊成功，我們需要防止黑客快速地計算密碼所對應的雜湊值。一個簡單的雜湊函式，如MD5，在一個現代的裝置上可以每秒執行上百萬次，甚至上億次。也就是說，如果我們使用一個簡單的雜湊函式，那麼在一秒鐘內可以有成千上萬個雜湊值參與比較。結果就是幾十秒鐘之內使用者所使用的密碼就可能被猜測出來了。因此對密碼進行加密的方法需要較為緩慢，以增加這種攻擊的難度。

　　但是呢，黑客手中還有一個利器，那就是平行計算。現在，構建一個可以進行平行計算的系統已經不再那麼昂貴，甚至只需要一個支援平行計算的普通的GPU。因此就算是計算一次密碼的雜湊值較為緩慢，黑客可以通過同時計算多個密碼所對應的雜湊值進行加速，使得暴力破解的速度幾十倍地增長。解決方法很簡單：選擇一個不支援平行計算的雜湊演算法。

　　OK，現在看來，我們已經對黑客所常用的攻擊方法進行了防禦。那麼就讓我們來總結一下進行加密的雜湊演算法所需要擁有的特徵：

1. 雜湊演算法需要是單向的。因為一旦使用了雙向雜湊演算法，那麼通過反向計算得到的字串常常只包含數字，字母以及常用的符號。這在黑客眼中是一個非常明顯的雜湊演算法猜測（接近）成功的訊號。接下來，他只需要對各個雜湊值反向計算即可得到相應的密碼。
2. 雜湊演算法的碰撞需要儘量少。因為如果N個不同的密碼能夠產生同一個雜湊值，那麼它被攻破的概率就大了N - 1倍。
3. 減慢雜湊的計算速度。這不僅僅需要減慢雜湊的計算速度，還需要令雜湊不支援平行計算。
4. Salt。Salt就是我們剛剛提到的用來在加密系統中用於選擇雜湊函式並增強密碼的組成。

Salt簡介

　　相信讀者對上面所提到的Salt不是很理解。例如：Salt中包含的值是什麼？如何使用？儲存在哪裡？

　　一個比較受歡迎的生成Salt的方法就是得到一個128位或更長的隨機整形資料並將其轉化為字串，或者是使用隨機生成的UUID。在使用者第一次設定其所使用的使用者名稱和密碼的時候，系統將為其生成一個Salt，並使用該Salt以及系統的加密方法計算使用者密碼的雜湊值，並將該雜湊值及Salt存在資料庫中。而在使用者再次登陸的時候，系統將根據使用者所輸入的密碼以及之前為使用者所生成的Salt再次使用系統的加密方法計算雜湊值，並將計算結果與資料庫內所儲存的雜湊值比較。如果兩個雜湊值相等，那麼就表示使用者所輸入的密碼是正確的，並登陸成功。

　　因為每次對密碼的操作都會用到這個Salt，因此我們常常將它與使用者名稱/密碼對同時儲存在資料庫中。在加密過程中，Salt也將會作為我們所使用的加密方法的一個輸入，以用來選擇加密方法中所使用的雜湊函式，並增強使用者所使用的密碼。從而使得對一系列密碼的字典攻擊以及Rainbow Table攻擊失效。

　　或許你還是不是非常理解它是如何使字典攻擊及Rainbow Table攻擊失效的。那麼我們假設現在一個黑客已經拿到了一系列的使用者名稱/密碼雜湊值組合。在攻擊時，他首先選取一個可能的密碼password，並使用選定的雜湊函式hash()進行加密操作hash(password)，並與所有的密碼雜湊值進行比較。一旦成功，那麼就基本上能確定選對了雜湊演算法。而如果雜湊過程中使用了Salt，那麼他所得到的資訊就是使用者名稱/密碼雜湊值/Salt。由於每個使用者的Salt並不相同，因此他需要根據各個使用者的Salt值來計算雜湊值，即hash(salt[0], password)，hash(salt[1], password)等等。這使得通過一次計算就可以和多個雜湊值進行比較變得不再可能。又由於雜湊演算法較為緩慢，因此黑客成功攻擊所需要的時間便大大增加。

　　前面已經說過，Rainbow Table攻擊是通過提前計算各個可能密碼的雜湊值來縮短時間的。而現在參與加密的Salt則是一個隨機字串，如“js98LP6h”，顯然Rainbow Table中所列出的可能的密碼將不會包含這種形式的密碼，從而使得Rainbow Table攻擊失效。

　　對Salt的一個常見誤區就是對Salt的使用可以增加破解單個密碼的難度。其實並不然。一般情況下，Salt都和雜湊過的密碼一樣存在於資料庫中。因此惡意人員在訪問到資料庫中所記錄的使用者名稱/密碼雜湊值對的同時也能訪問到雜湊所需要使用的Salt。因此在嘗試攻擊時，其可以直接使用他所得到的Salt和密碼字典中列出的各可能密碼結合在一起計算雜湊值。對這種攻擊的防禦是通過減慢雜湊計算速度來完成的，而Salt則是用來防禦並行攻擊，即一次計算雜湊就可以和多個雜湊進行比較。

選擇合適的加密方法

　　實際上，業內已經有很多用來對密碼進行加密的方法了，如PBKDF2，bcrypt，scrypt等。這些加密方法各有優劣。因此在需要保護使用者的密碼時，我們需要儘量從這些標準加密方法中選擇。在使用這些加密方法時，您還需要指定迭代次數等眾多引數。這些引數對於網站本身來說都是機密，因此不要將它們存在資料庫中，以免在資料庫洩露的時候同時丟失這些設定，進而導致這些加密演算法的使用細節洩露，減弱加密方法的安全性。

　　反過來，自行定義一個加密方法實際上是並不被建議的。實際上，設計一個加密演算法是一個非常嚴肅的事情。我們所熟知的各種加密演算法，如SHA演算法集，實際上都經歷了很嚴謹地論證才被宣佈是安全的。首先密碼學專家要經過非常細緻地研究才提出加密方案，然後在業內的各種討論中，這些加密方案將被彼此進行比較，競爭，並最終經過數年時間驗證才宣佈是安全的。

　　也正是因為我們自己並不是密碼學專家，因此我們所創建出來的加密演算法相較於這種經過嚴謹考驗的各個加密演算法而言將是非常不安全的。

　　一個比較容易讓人產生疑惑的就是加密演算法中的碰撞。我們常常說MD5已經不再認為是安全的加密演算法了。這是因為惡意人員可以很容易地找到一系列輸入，使它們所產生的MD5是相同的。這在一系列驗證領域中是不安全的，如檔案的校驗。因為在進行MD5校驗的時候，惡意軟體可以通過使它的MD5與目標檔案相等而繞過MD5校驗。但是密碼的加密演算法所要求的則是在經過加密後不能逆向解析出被加密的密碼，因此它仍然是一種安全的加密演算法。只是由於其計算速度過快，因此不建議被單獨使用。

本文章由專業律師事務所執行版權保護。授權範圍僅限於個人轉載，並需要在題目中標明轉載