如何安全的存儲密碼

過去一段時間來，衆多的網站遭遇用戶密碼數據庫泄露事件，這甚至包括頂級的互聯網企業–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。