這些事件中最令業界瞠目的是RSA被入侵，這直接導致多家工業巨頭遭遇連鎖的攻擊，很多安全企業本身也使用RSA的令牌。比RSA弱小很多的荷蘭電子認證公司DigiNotar已經在被入侵后，宣告破產。

就在2011年上半年，我們還是站在旁觀者的立場討論這些事情。但隨即我們就遭遇了CSDN、多玩和天涯等等的數據泄露，其中最為敏感的，一方面是用戶信息，另一個當然就是用戶口令。由于身份實名、口令通用等情況影響，一時間人人自危。各個站點也陷在口水當中。

但實際上根據推斷，這些入侵都是一些過去時，也就是說這些庫早就在地下流傳。同時流出，也許就是一個集體性的心理效應。

這種針對數據庫記錄的竊取，被一些攻擊者稱為“拖庫“，于是有了一個自然而諧音的戲稱“脫褲”。只是攻擊者日趨不厚道，從前只是偷了人家的褲子，現在還要晾在大街上，并貼上布告說，“看，丫褲子上還有補丁呢”。

如果拖庫是很難避免的，那么采用合理的加密策略，讓攻擊者拿到庫后的影響降低到更小就是必要的。

明文存放口令的時代肯定是要結束了，但加密就安全么?

那些錯誤的加密策略

明文的密碼固然是不能接受的，但錯誤的加密策略同樣很糟糕。讓我們看看下列情況。

簡單使用標準HASH

我想起了一個90年代黑客笑話，有人進入一臺UNIX主機，抓到了一個shadow文檔，但破解不了。于是，他用自己的機器做了一個假的現場，故意留下這個shadow，最后看看別人用什么口令來試，最后再用這些口令與滲透原來的主機。遺憾的是，那時我們都把這個當成一個Joke，充其量回復一句“I服了you!“，而沒有反思使用標準算法的問題。

目前來看，在口令保存上，使用最為廣泛的算法是標準MD5 HASH。但實際上，很長時間，我們都忽略了HASH設計的初衷并不是用來加密，而是用來驗證。系統設計者是因為HASH算法具有不可逆的特點所以“借”用其保存密碼的。但其不可逆的前提假設，是明文集合是無限大的。但放到口令并不一樣，口令的長度是受限的，同時其可使用的字符也是受限的。我們可以把口令的總數看正一個事實上的有限集(很難想象有人用100個字符作為口令)。

比如一個人的密碼是“123456”，那么任何采用標準MD5加密的網站數據庫中，其存放的都是這樣一個MD5值：E10ADC3949BA59ABBE56E057F20F883E

由于密文均相同，加之HASH算法是單向的，因此攻擊者較早使用的方法就是“密文比對+高頻統計“后生成密文字典來攻擊，由于絕大多數網站和系統的加密實現，都是相同明文口令生成相同的密文，因此，那些有高頻密文的用戶就可能是使用高頻明文口令的用戶。攻擊者一方面可以針對標準算法來制定高頻明文的對應密文檔來查詢，另一方面，對于那些非標準算法，高頻統計攻擊的方法也非常常見。

但查表攻擊迅速壓倒高頻統計的原因，正是從2000年開始陸續有網站規模性明文口令泄漏事件開始的。在過去每一次明文的密碼泄漏事件，攻擊者都會把使用MD5、SHA1等常見HASH算法加工成的口令與那些采用HASH值來保存的庫進行應對。

隨著超算資源的廉價、GPU的普及、存儲能力的增長，一個不容忽視的威脅開始躍上桌面，那就是，這些巨大的HASH表已經不僅僅是基于泄漏的密碼和常見字符串字典來制作，很多攻擊者通過長期的分工協作，通過窮舉的方式來制作一定位數以下的數字字母組合的口令串與多種算法加密結果的映射結果集，這些結果集從百GB到幾十TB，這就是傳說中的彩虹表。

HASH的單向性優勢在此已經只有理論意義，因為HASH的單向性是靠算法設計保證的，使用一個有限集來表示一個無限集，其必然是不可逆的。但攻擊者是從查表來完成從HASH到口令明文的還原的。因此其算法的單向性也就失去了意義。

聯合使用HASH

一些人誤以為，HASH不夠安全是因為HASH算法的強度問題，因此把MD5或者SHA1聯合使用，其實這是毫無價值的(只是徒耗了存儲資源)。如上面所說，HASH的不安全性在于大量口令與其HASH值的對應關系早已經被制作成彩虹表。只要你聯合使用HASH的算法其中之一在彩虹表中，自然就可以查到了。

同理，那種采用“MD5的頭+SHA的尾“之類的，或者采用其他的混合兩個值的方法，也一樣是沒有意義的。因為攻擊者可以很容易的觀察到這種組合方法的規律，經過拆解后繼續按照查表法破解。

自己設計算法

我一向認為，既然我們不是一個密碼學家，而是工程師、程序員，那么放著現成的好東西不用，自己開發加密算法是相當愚蠢的事情。我相信很多程序員都遇到過挖空心思想到了一個“新算法”，然后發現早在某篇20世紀80年代的數學論文里，早就提出了相關算法的情況。

況且在開源時代，很多算法不僅被實現和發布了，而且還經歷了長期的使用推敲。這些都是自己設計、自己實現無法比擬的。

關于自主設計的算法的不安全性，有一個事情深達我腦海。記得我在證券系統工作時，由于剛剛接手收購來的營業部，需要把一個clipper編譯的柜臺系統進行遷移，但原來的開發商已經聯系不到了，當時我們制定了兩條路，一位高手李老師負責，進行數據破解，看看是否能還原明文，而我則負責破解算法，如果李老師那邊走不通，則我需要解出算法，把000000～999999之間的數字全部加密，然后用密文做碰撞(那時證券都是柜臺操作，沒有網上炒股，密碼都是柜臺用數字鍵盤輸入的)。

由于原來的開發者加了一點花活，我這邊還沒有眉目，那邊旁觀李老師的工程師，已經發出了驚嘆之聲，我跑過去，只見李老師根據構造的幾個密碼的加密結果，在紙上匯出了長得非常像楊輝三角的東西。不到半個小時，李老師已經連解密程序一起做好了。

上面故事的目的是說明，自己設計算法無論怎么自我感覺良好，看看美國官方遴選算法的PK過程大家就明白了，我們無法和全球數學家的智慧組合對抗。

因此自己設計實現算法，并不是一個好主意。這其中也包括，在實現上會不會有類似輸入超長字符串會溢出一類的Bug。

單獨使用對稱算法

在標準HASH安全破滅后，又看到有人呼吁用AES，其實這不是一個好建議。AES這些對稱算法，都不具備單向性。網站被攻擊的情況是復雜的，有的是只有數據庫被拖，有的則整個環境淪陷。而后者AES密鑰一旦被拿到，密碼就會被還原出來，這比被查表還要壞。

當然我們還看到一種把AES當HASH用的思想，就是只保留一部分的AES加密結果，只驗證不還原。但其實這樣的AES并不見得比HASH有優勢。比如即使攻擊者沒有拿到密鑰，也只拖了庫，但攻擊者自己在拖庫之前注冊了足夠多的帳號，并使用大量不同的短口令。那么就拿到了一組短明文和對應密文。而此時密鑰是完全有可能被分析出來的。

而使用DES、AES一類的算法，還是使用標注HASH，還是自己設計算法，如果不解決不同用戶相同口令密文相同的統計性缺陷，那么攻擊者即使拿不到密鑰，也都可以先把一些高頻口令用于帳號注冊，拖庫后進行密文比對。就可以鎖定大量的采用常見口令的用戶。

加“一粒鹽”

其實很多同仁都指出了哈希加鹽法(HASH+SALT)，是問題的解決之道，所謂加鹽(SALT)其實很簡單，就是在生成HASH時給予一個擾動，使HASH值與標準的HASH結果不同，這樣就可以抗彩虹查表了。

比如說，用戶的密碼是123456，加一個鹽，也就是隨機字符串“1cd73466fdc24040b5”，兩者合到一起，計算MD5，得到的結果是6c9055e7cc9b1bd9b48475aaab59358e。通過這種操作，即便用戶用的弱密碼，也通過加鹽，使實際計算哈希值的是一個長字符串，一定程度上防御了窮舉攻擊和彩虹表攻擊。

但從我們審計過的實現來看，很多人只加了“一粒鹽”。也就是說，對同一個站點，不同用戶使用同一個密碼，其密文還是相同的。這就又回到了會遭遇高頻統計攻擊，預先注冊攻擊等問題。

口令的安全策略

在傳統密碼學家眼中只有一種加密是理想的，那就是“一次一密”，當然事實上這是不可能的。但如果我們套用這種詞法，我們也可以說，口令安全策略的理想境界，我們可以稱為單向、一人一密、一站一密。

單向：標準HASH算法的價值盡管在這個場景下，已經被推倒，但其單向性的思想依然是正確的，口令只要是能還原的，就意味著攻擊者也能做到這一點，從而失去了意義，因此使用單向算法是必須的。

一人一密：同一個站點設置同樣口令的不同用戶，加密生成的密文內容并不相同。這樣就能有效的應對結果碰撞和統計攻擊。采用字典的攻擊的方法基本是不收斂的。

一站一密：僅僅保證一人一密是不夠的，還要保證使用同樣信息、同樣口令去注冊不同網站的用戶，在不同站點的口令加密結果是不同的。鑒于有大量用戶用同樣的信息、同樣的口令去注冊不同網站，如果能做到這一點，流失出的庫信息會進一步打折扣。而攻擊者基本會放棄生成密文字典的嘗試。

實現這些說起來很簡單，依然是HASH+SALT，關鍵在于每個站點要有不同的SALT，每個用戶要有不同的鹽。

但如果攻擊者不是只獲得了庫，而且也獲得了相關的加密參數和密鑰，我們就要看到攻擊者依然可以自己通過相關參數和密鑰調用算法，使用常見密碼對每個用戶生成一遍密文，然后是否有匹配。當然我們可以看到由于“每人一粒鹽”的策略，攻擊者所需要的計算代價已經變化了，如果過去只需要生成一次的話，那么假如使用100個常見的口令來做，那么只要口令沒有碰撞到，對每個用戶都要做100次加密操作。但這也是不容小覷的威脅。因為有太多用戶喜歡使用那些常見口令。

因此，設定一個密碼禁用表，讓用戶避免使用常見口令，可以進一步讓破解者付出更大的代價，從而最終導致計算資源不收斂而放棄，也可以是一個可以考慮的策略。但也需要提醒服務器之家的是，這樣會增大你的用戶忘記口令的風險。

另外，用戶是否有把密碼設置為123456的自由呢，我想只要不是國防、航天、涉密系統和有安全要求的企業環境，如果只是潛潛水、罵罵街，網站或許提醒用戶就好，但也許并不需要做成強制策略。

具體的實現

了這么多，怎么來具體實現一站一密、一人一密的策略呢，2011年12月23號，我們想到與其空洞的說教算法原理和策略，不如提供一些非常直接的示例程序和文檔。

因此同事們寫了一份名為Antiy Password Mixer(安天密碼混合器)的開源代碼，當然這沒有什么技術含量，也不是“自有知識產權的國產算法”，有的只是對實現較好的流行開源算法包的示范性使用而已，目前的Python版本，也只有三百行代碼，在其中封裝了RSA和HASH+SALT使用，并給出了具體的在初始化、注冊和認證時如何使用的范例文檔。

大家可以在這里找到這個東西：http://code.google.com/p/password-mixer/

當然，就像我們惋惜很多應用開發者缺乏對安全的重視一樣，其實我們并不懂應用開發，所以這些代碼和文檔對于應用開發者看來可能非常丑陋。盡管可能被鄙視，我們還是要打開門，證明安全團隊并不保守。

而同時，我們必須與應用走得更近，因為我們也在使用著這些自認為違反了某種安全原則的應用，卻因為不是其開發者而無法改造它們。

過去的10余年，中國的Web應用甩開安全而飛速狂奔，開發者們憑借自身的勤奮和沖擊力奠定了現有的格局，但也因快速地奔跑遺落了一些東西，比如安全。也許現在是拾起這些棄物的時間了。

中國的安全界則因保守、敏感和很多自身的原因，與應用的距離越拉越遠，在我們還在幻想某些完美的安全圖景時，發現我們已經望不到應用的脊背了。也許，在應用會回頭等等我們的時候，就是我們加速前行、拾起應用所遺落的安全性，追送上去的時間了。