如何安全的儲存密碼

　　過去一段時間來，眾多的網站遭遇使用者密碼資料庫洩露事件，這甚至包括頂級的網際網路企業–NASDQ上市的商務社交網路Linkedin，國內諸如CSDN一類的就更多了。

　　層出不窮的類似事件對使用者會造成巨大的影響，因為人們往往習慣在不同網站使用相同的密碼，一家“暴庫”，全部遭殃。

　　那麼在選擇密碼儲存方案時，容易掉入哪些陷阱，以及如何避免這些陷阱？我們將在實踐中的一些心得體會記錄於此，與大家分享。

　　菜鳥方案：

　　直接儲存使用者密碼的明文或者將密碼加密儲存。

　　曾經有一次我在某知名網站重置密碼，結果郵件中居然直接包含以前設定過的密碼。我和客服諮詢為什麼直接將密碼傳送給使用者，客服答曰：“減少使用者步驟，使用者體驗更好”；再問“管理員是否可以直接獲知我的密碼”， 客服振振有詞：“我們用XXX演算法加密過的，不會有問題的”。 殊不知，密碼加密後一定能被解密獲得原始密碼，因此，該網站一旦資料庫洩露，所有使用者的密碼本身就大白於天下。

　　以後看到這類網站，大家最好都繞道而走，因為一家“暴庫”，全部遭殃。

　　入門方案：

　　將明文密碼做單向雜湊後儲存。

　　單向雜湊演算法有一個特性，無法通過雜湊後的摘要(digest)恢復原始資料，這也是“單向”二字的來源，這一點和所有的加密演算法都不同。常用的單向雜湊演算法包括SHA-256，SHA-1，MD5等。例如，對密碼“passwordhunter”進行SHA-256雜湊後的摘要(digest)如下：
“bbed833d2c7805c4bf039b140bec7e7452125a04efa9e0b296395a9b95c2d44c”

　　可能是“單向”二字有誤導性，也可能是上面那串數字唬人，不少人誤以為這種方式很可靠， 其實不然。

　　單向雜湊有兩個特性：

　　1）從同一個密碼進行單向雜湊，得到的總是唯一確定的摘要

　　2）計算速度快。隨著技術進步，尤其是顯示卡在高效能運算中的普及，一秒鐘能夠完成數十億次單向雜湊計算

　　結合上面兩個特點，考慮到多數人所使用的密碼為常見的組合，攻擊者可以將所有密碼的常見組合進行單向雜湊，得到一個摘要組合，然後與資料庫中的摘要進行比對即可獲得對應的密碼。這個摘要組合也被稱為rainbow table。

　　更糟糕的是，一個攻擊者只要建立上述的rainbow table，可以匹配所有的密碼資料庫。仍然等同於一家“暴庫”，全部遭殃。以後要是有某家廠商宣佈“我們的密碼都是雜湊後儲存的，絕對安全”，大家對這個行為要特別警惕並表示不屑。有興趣的朋友可以搜尋下，看看哪家廠商躺著中槍了。

　　進階方案：

　　將明文密碼混入“隨機因素”，然後進行單向雜湊後儲存，也就是所謂的“Salted Hash”。

　　這個方式相比上面的方案，最大的好處是針對每一個資料庫中的密碼，都需要建立一個完整的rainbow table進行匹配。 因為兩個同樣使用“passwordhunter”作為密碼的賬戶，在資料庫中儲存的摘要完全不同。

　　10多年以前，因為計算和記憶體大小的限制，這個方案還是足夠安全的，因為攻擊者沒有足夠的資源建立這麼多的rainbow table。 但是，在今日，因為顯示卡的恐怖的平行計算能力，這種攻擊已經完全可行。

　　專家方案：

　　故意增加密碼計算所需耗費的資源和時間，使得任何人都不可獲得足夠的資源建立所需的rainbow table。

　　這類方案有一個特點，演算法中都有個因子，用於指明計算密碼摘要所需要的資源和時間，也就是計算強度。計算強度越大，攻擊者建立rainbow table越困難，以至於不可繼續。

　　這類方案的常用演算法有三種：

　　1）PBKDF2(Password-Based Key Derivation Function)

　　PBKDF2簡單而言就是將salted hash進行多次重複計算，這個次數是可選擇的。如果計算一次所需要的時間是1微秒，那麼計算1百萬次就需要1秒鐘。假如攻擊一個密碼所需的rainbow table有1千萬條，建立所對應的rainbow table所需要的時間就是115天。這個代價足以讓大部分的攻擊者忘而生畏。

　　美國政府機構已經將這個方法標準化，並且用於一些政府和軍方的系統。 這個方案最大的優點是標準化，實現容易同時採用了久經考驗的SHA演算法。

　　2）bcrypt

　　bcrypt是專門為密碼儲存而設計的演算法，基於Blowfish加密演算法變形而來，由Niels Provos和David Mazières發表於1999年的USENIX。

　　bcrypt最大的好處是有一個引數（work factor)，可用於調整計算強度，而且work factor是包括在輸出的摘要中的。隨著攻擊者計算能力的提高，使用者可以逐步增大work factor，而且不會影響已有使用者的登陸。

　　bcrypt經過了很多安全專家的仔細分析，使用在以安全著稱的OpenBSD中，一般認為它比PBKDF2更能承受隨著計算能力加強而帶來的風險。bcrypt也有廣泛的函式庫支援，因此我們建議使用這種方式儲存密碼。

　　3) scrypt

　　scrypt是由著名的FreeBSD黑客 Colin Percival為他的備份服務 Tarsnap開發的。

　　和上述兩種方案不同，scrypt不僅計算所需時間長，而且佔用的記憶體也多，使得平行計算多個摘要異常困難，因此利用rainbow table進行暴力攻擊更加困難。scrypt沒有在生產環境中大規模應用，並且缺乏仔細的審察和廣泛的函式庫支援。但是，scrypt在演算法層面只要沒有破綻，它的安全性應該高於PBKDF2和bcrypt。