玄幻小说完本,有声小说,我吃西红柿

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

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

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

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

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

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

　　那些錯誤的加密策略

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

　　簡單使用標準HASH

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

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

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

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

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

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

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

　　聯(lián)合使用HASH

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

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

　　自己設(shè)計算法

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

　　況且在開源時代，很多算法不僅被實現(xiàn)和發(fā)布了，而且還經(jīng)歷了長期的使用推敲。這些都是自己設(shè)計、自己實現(xiàn)無法比擬的。

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

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

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

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

　　單獨使用對稱算法

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

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

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

　　加“一粒鹽”

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

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

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

　　口令的安全策略

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

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

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

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

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

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

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

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

　　具體的實現(xiàn)

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

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

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

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

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

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

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

您可能感興趣的文章:

asp.net2.0如何加密數(shù)據(jù)庫聯(lián)接字符串
加密你的Access數(shù)據(jù)庫asp打開方法
使用 Salt + Hash 將密碼加密后再存儲進數(shù)據(jù)庫
在asp.net中使用加密數(shù)據(jù)庫聯(lián)接字符串保證數(shù)據(jù)安全
ASP.NET web.config中數(shù)據(jù)庫連接字符串加密解密

標簽：廣西玉溪撫順濟源瀘州商洛文山吉林

巨人網(wǎng)絡(luò)通訊聲明：本文標題《由拖庫攻擊談口令字段的加密策略(數(shù)據(jù)庫加密)》，本文關(guān)鍵詞由,拖庫,攻擊,談,口令,字段,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。