建站
咨詢
售后
建站咨詢
新聞中心
0×00 前言
創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)整合營(yíng)銷推廣、網(wǎng)站重做改版、館陶網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5高端網(wǎng)站建設(shè)、商城建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為館陶等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
天下武功，唯快不破。但密碼加密不同。算法越快，越容易破。
0×01 暴力破解
密碼破解，就是把加密后的密碼還原成明文密碼。似乎有不少方法，但最終都得走一條路：暴力窮舉。也許你會(huì)說還可以查表，瞬間就出結(jié)果。雖然查表不用窮舉，但表的制造過程仍然需要。查表只是將窮舉提前了而已。
密碼加密，用的都是單向散列計(jì)算。既然單向，那就是不可逆，那只能窮舉。窮舉的原理很簡(jiǎn)單。只要知道密文是用什么算法加密的，我們也用相同的算法，把常用的詞組跑一遍。若有結(jié)果和密文一樣，那就猜中了。
窮舉的速度有多快？這和加密算法有關(guān)。加密一次有多快，猜一次也這么快。例如 MD5 加密是非?？斓?。加密一次耗費(fèi) 1 微秒，那破解時(shí)隨便猜一個(gè)詞組，也只需 1 微秒（假設(shè)機(jī)器性能一樣，詞組長(zhǎng)度也差不多）。攻擊者一秒鐘就可以猜 100 萬(wàn)個(gè)，而且這還只是單線程的速度。
所以，加密算法越快，破解起來(lái)就越容易。
（題圖來(lái)自： netdna-ssl.com）
0×02 慢加密
如果能提高加密時(shí)間，顯然也能增加破解時(shí)間。如果加密一次提高到 10 毫秒，那么攻擊者每秒只能猜 100 個(gè)，破解速度就慢了一萬(wàn)倍。怎樣才能讓加密變慢？最簡(jiǎn)單的，就是對(duì)加密后的結(jié)果再加密，重復(fù)多次。
例如，原本 1 微秒的加密，重復(fù)一萬(wàn)次，就慢一萬(wàn)倍了：
- for i = 0 ~ 10000
- x = md5(x)
- end
加密時(shí)多花一點(diǎn)時(shí)間，就可以換取攻擊者大量的破解時(shí)間。
事實(shí)上，這樣的「慢加密」算法早已存在，例如 bcrypt、PBKDF2 等等。它們都有一個(gè)難度系數(shù)因子，可以控制加密時(shí)間，想多慢就多慢。
加密越慢，破解時(shí)間越長(zhǎng)。
0×03 慢加密應(yīng)用
最需要慢加密的場(chǎng)合，就是網(wǎng)站數(shù)據(jù)庫(kù)里的密碼。
近幾年，經(jīng)常能聽到網(wǎng)站被「拖庫(kù)」的新聞。用戶資料都是明文存儲(chǔ)，泄露了也無(wú)法挽回。唯獨(dú)密碼，還可以和攻擊者對(duì)抗一下。然而不少網(wǎng)站，使用的都是 快速加密算法，因此輕易就能破解出一堆弱口令賬號(hào)。當(dāng)然，有時(shí)只想破解某個(gè)特定人物的賬號(hào)。只要不是特別復(fù)雜的詞匯，跑上幾天，很可能就破出來(lái)。
但網(wǎng)站用了慢加密，結(jié)果可能就不一樣了。如果把加密時(shí)間提高 100 倍，破解時(shí)間就得長(zhǎng)達(dá)數(shù)月，變得難以接受。即使數(shù)據(jù)泄露，也能保障「密碼」這最后一道隱私。
0×04 慢加密缺點(diǎn)
不過，慢加密也有明顯的缺點(diǎn)：消耗大量計(jì)算資源。使用慢加密的網(wǎng)站，如果同時(shí)來(lái)了多個(gè)用戶，服務(wù)器 CPU 可能就不夠用了。要是遇到惡意用戶，發(fā)起大量的登錄請(qǐng)求，甚至造成資源被耗盡。性能和安全總是難以兼得。所以，一般也不會(huì)使用太高的強(qiáng)度。
一些大型網(wǎng)站，甚至為此投入集群，用來(lái)處理大量的加密計(jì)算。但這需要不少的成本。
有沒有什么方法，可以讓我們使用算力強(qiáng)勁、同時(shí)又免費(fèi)的計(jì)算資源？
0×05 前端加密
在過去，個(gè)人電腦和服務(wù)器的速度，還是有較大差距的。但如今，隨著硬件發(fā)展進(jìn)入瓶頸，這個(gè)差距正縮小。在單線任務(wù)處理上，甚至不相上下?？蛻舳藫碛袕?qiáng)大的算力，能不能分擔(dān)一些服務(wù)器的工作？尤其像「慢加密」這種算法開源、但計(jì)算沉重的任務(wù)，為何不交給客戶端來(lái)完成？
過去，提交的是明文密碼；現(xiàn)在，提交的則是明文密碼的「慢加密結(jié)果」。無(wú)論是注冊(cè)，還是登錄。而服務(wù)端，無(wú)需任何改動(dòng)。將收到的「慢加密結(jié)果」，當(dāng)做原來(lái)的明文密碼 就行。以前是怎么保存的，現(xiàn)在還是怎么保存。這樣就算被拖庫(kù)，攻擊者破解出來(lái)的也只是「慢加密結(jié)果」，還需再破解一次，才能還原出「明文密碼」。
事實(shí)上，「慢加密結(jié)果」這個(gè)中間值，是不可能破解出來(lái)的！因?yàn)樗且粋€(gè)散列值 —— 毫無(wú)規(guī)律的隨機(jī)串，例如 32 位十六進(jìn)制字符串，而字典都是有意義的詞組，幾乎不可能跑到它！除非字節(jié)逐個(gè)窮舉。但這有 16^32 種組合，是個(gè)天文數(shù)字。所以「慢加密結(jié)果」是無(wú)法通過數(shù)據(jù)庫(kù)里泄露的密文「逆推」出來(lái)的。
或許你在想，即使不知道明文密碼，也可以直接用「慢加密結(jié)果」來(lái)登錄。事實(shí)上后端儲(chǔ)存時(shí)再次加密，就無(wú)法逆推出這個(gè)散列值了。
當(dāng)然，不能逆推，但可以順推。把字典里的詞組，用前后端的算法依次執(zhí)行一次：
- back_fast_hash( front_slow_hash(password) )
然后對(duì)比密文，即可判斷有沒有猜中。這樣就可以用跑字典來(lái)破解。但是有 front_slow_hash 這個(gè)障礙，破解速度就大幅降低了。
0×06 對(duì)抗預(yù)先計(jì)算
不過，前端的一切都是公開的。所以 front_slow_hash 的算法大家都知道。攻擊者可以用這套算法，把常用詞組的「慢加密結(jié)果」提前算出來(lái)，制作成一個(gè)「新字典」。將來(lái)拖庫(kù)后，就可以直接跑這個(gè)新字典了。
對(duì)抗這種方法，還得用經(jīng)典的手段：加鹽。最簡(jiǎn)單的，將用戶名作為鹽值：
- front_slow_hash(password + username)
這樣，即使相同的密碼，對(duì)于不同的用戶，「慢加密結(jié)果」也不一樣了。也許你會(huì)說，這個(gè)鹽值不合理，因?yàn)橛脩裘枪_的。攻擊者可以對(duì)某個(gè)重要人物的賬號(hào)，單獨(dú)為他建立一個(gè)字典。
那么，是否可以提供一個(gè)隱蔽的鹽值？答案是：不可以。
因?yàn)檫@是在前端。用戶還沒登錄，那返回誰(shuí)的鹽值？登錄前就能獲得賬號(hào)的鹽值，這不還是公開的嗎。所以，前端加密的鹽值無(wú)法隱藏，只能公開。當(dāng)然，即使公開，單獨(dú)提供一個(gè)鹽值參數(shù)，也比用戶名要好。因?yàn)橛脩裘肋h(yuǎn)不變，而獨(dú)立的鹽值可以定期更換。
鹽值可以由前端生成。例如注冊(cè)時(shí)：
# 前端生成鹽值
salt = rand()
password = front_slow_hash(password + salt)
# 提交時(shí)帶上鹽值
submit(..., password, salt)
后端將用戶的鹽值也儲(chǔ)存起來(lái)。登錄時(shí)，輸完用戶名，就可以開始查詢用戶對(duì)應(yīng)的鹽值：
當(dāng)然要注意的是，這個(gè)接口可以測(cè)試用戶是否存在，所以得有一定的控制。
鹽值的更換，也非常簡(jiǎn)單，甚至可以自動(dòng)完成：
前端在加密當(dāng)前密碼時(shí)，同時(shí)開啟一個(gè)新線程，計(jì)算新鹽值和新密碼。提交時(shí)，將它們?nèi)紟?。如果「?dāng)前密碼」驗(yàn)證成功，則用「新密碼」和「新鹽值」覆蓋舊的。這樣更換鹽值，還是只用到前端的算力。
這一切都是自動(dòng)的，相當(dāng)于 在用戶無(wú)感知的情況下，定期幫他更換密碼！
密文變了，針對(duì)「特定鹽值」制作的字典，也就失效了。攻擊者得重新制作一次。
0×07 強(qiáng)度策略
密碼學(xué)上的問題到此結(jié)束，下面討論實(shí)現(xiàn)上的問題。
現(xiàn)實(shí)中，用戶的算力是不均衡的。有人用的是神級(jí)配置，也有的是古董機(jī)。這樣，加密強(qiáng)度就很難設(shè)定。如果古董機(jī)用戶登錄會(huì)卡上幾十秒，那肯定是不行的。對(duì)于這種情況，只有以下選擇：
-
強(qiáng)度固定
-
強(qiáng)度可變
1.強(qiáng)度固定
根據(jù)大眾的配置，制定一個(gè)適中的強(qiáng)度，絕大多數(shù)用戶都可接受。但如果超過規(guī)定時(shí)間還沒完成，就把算到一半的 Hash 和步數(shù)提交上來(lái)，剩余部分讓服務(wù)器來(lái)完成。
[前端] 完成 70% ----> [后端] 計(jì)算 30%
不過，這需要「可序列化」的算法，才能在服務(wù)端還原進(jìn)度。如果計(jì)算中會(huì)有大量的臨時(shí)內(nèi)存，這種方案就不可行了。相比過去 100% 后端慢加密，這種少量用戶「前后參半」的方式，可以節(jié)省不少服務(wù)器資源。
對(duì)于請(qǐng)求協(xié)助的用戶，也必須有一定的限制，防止惡意透支服務(wù)器資源。
2.強(qiáng)度可變
如果后端不提供任何協(xié)助，那只能根據(jù)自身?xiàng)l件做取舍了。配置差的用戶，就少加密一點(diǎn)。用戶注冊(cè)時(shí)，加密算法不限步數(shù)放開跑，看看特定時(shí)間里能算到多少步：
- # [注冊(cè)階段] 算力評(píng)估（線程 1 秒后中止）
- while
- x = hash(x)
- step = step + 1
- end
這個(gè)步數(shù)，就是加密強(qiáng)度，會(huì)保存到他的賬號(hào)信息里。和鹽值一樣，強(qiáng)度也是公開的。因?yàn)樵诘卿洉r(shí)，前端加密需要知道這個(gè)強(qiáng)度值。
- # [登錄階段] 先獲得 step
- for i = 0 ~ step
- x = hash(x)
- end
這個(gè)方案，可以讓高配置的用戶享受更高的安全性；低配置的用戶，也不會(huì)影響基本使用。（用上好電腦還能提升安全性，很有優(yōu)越感吧~）
但這有個(gè)重要的前提：注冊(cè)和登錄，必須在性能相近的設(shè)備上。如果是在高配置電腦上注冊(cè)的賬號(hào)，某天去古董機(jī)登錄，那就悲劇了，可能半天都算不出來(lái)。
3.動(dòng)態(tài)調(diào)整方案
上述情況，現(xiàn)實(shí)中是普遍存在的。比如 PC 端注冊(cè)的賬號(hào)，在移動(dòng)端登錄，算力可能就不夠用。如果沒有后端協(xié)助，那只能等。要是經(jīng)常在低端設(shè)備上登錄，那每次都得干等嗎？等一兩次就算了，如果每次都 等，不如重新估量下自己的能力吧。把加密強(qiáng)度動(dòng)態(tài)調(diào)低，更好的適應(yīng)當(dāng)前環(huán)境。將來(lái)如果不用低端設(shè)備了，再自動(dòng)的調(diào)整回來(lái)。讓加密強(qiáng)度，能動(dòng)態(tài)適應(yīng)常用的設(shè) 備的算力。
實(shí)現(xiàn)原理，和上一節(jié)的自動(dòng)更換鹽值類似。
4.異想天開方案
下面 YY 一個(gè)腦洞大開的方案，前提是網(wǎng)站有足夠大的訪問量。如果當(dāng)前有很多在線用戶，它們不就是一堆免費(fèi)的計(jì)算節(jié)點(diǎn)嗎？計(jì)算量大的問題，扔給他們來(lái)解決。
不過這樣做也有一些疑慮，萬(wàn)一正好推送給了壞人怎么辦？顯然，不能把太多的敏感數(shù)據(jù)放出去。節(jié)點(diǎn)只管計(jì)算，完全不用知道、也不能知道這個(gè)任務(wù)的最終目的。
但是，如果遇到惡作劇節(jié)點(diǎn)，故意把數(shù)據(jù)算錯(cuò)怎么辦？所以不能只推送給一個(gè)節(jié)點(diǎn)。多選幾個(gè)，最終結(jié)果一致才算正確。這樣風(fēng)險(xiǎn)概率就降低了。
相比 P2P 計(jì)算，網(wǎng)站是有中心、實(shí)名的，管理起來(lái)會(huì)容易一些。對(duì)于惡作劇用戶，可以進(jìn)行懲罰；參與過幫助的用戶，也給予一定獎(jiǎng)勵(lì)。
想象就到此，繼續(xù)討論實(shí)際的。
0×08 性能優(yōu)化
1.為什么要優(yōu)化
或許你會(huì)問，「慢加密」不就是希望計(jì)算更慢嗎，為什么還要去優(yōu)化？
假如這是一個(gè)自創(chuàng)的隱蔽式算法，并且混淆到外人根本無(wú)法讀懂，那不優(yōu)化也沒事。甚至可以在里面放一些空循環(huán)，故意消耗時(shí)間。但事實(shí)上，我們選擇的肯 定是「密碼學(xué)家推薦」的公開算法。它們每一個(gè)操作，都是有數(shù)學(xué)上的意義的。原本一個(gè)操作只需一條 CPU 指令，因?yàn)椴粔騼?yōu)化，用了兩條指令，那么額外的時(shí)間就是內(nèi)耗。導(dǎo)致加密用時(shí)更久，強(qiáng)度卻未提升。
2.前端計(jì)算軟肋
如果是本地程序，根本不用考慮這個(gè)問題，交給編譯器就行。但在 Web 環(huán)境里，我們只能用瀏覽器計(jì)算！相比本地程序，腳本要慢的多，因此內(nèi)耗會(huì)很大。
腳本為什么慢？主要還是這幾點(diǎn)：
-
弱類型
-
解釋型
-
沙箱
3.弱類型
腳本，是用來(lái)處理簡(jiǎn)單邏輯的，并不是用來(lái)密集計(jì)算的，所以沒必要強(qiáng)類型。不過如今有了一個(gè)黑科技：asm.js。它能通過語(yǔ)法糖，為 JS 提供真正的強(qiáng)類型。這樣計(jì)算速度就大幅提升了，可以接近本地程序的性能！
但是不支持 asm.js 的瀏覽器怎么辦？例如，國(guó)內(nèi)還有大量的 IE 用戶，他們的算力是非常低的。好在還有個(gè)后補(bǔ)方案 —— Flash，它有各種高性能語(yǔ)言的特征。類型，自然不在話下。
相比 asm.js，F(xiàn)lash 還是要慢一些，但比 IE 還是快多了。
4.解釋型
解釋型語(yǔ)言，不僅需要語(yǔ)法分析，更是失去了「編譯時(shí)深度優(yōu)化」帶來(lái)的性能提升。好在 Mozilla 提供了一個(gè)可以從 C/C++ 編譯成 asm.js 的工具：emscripten。有了它，就不用裸寫了。而且編譯時(shí)經(jīng)過 LLVM 的優(yōu)化，生成的代碼質(zhì)量會(huì)更高。
事實(shí)上，這個(gè)概念在 Flash 里早有了。曾經(jīng)有個(gè)叫 Alchemy 的工具，能把 C/C++ 交叉編譯成 Flash 虛擬機(jī)指令，速度比 ActionScript 快不少。
Alchemy 現(xiàn)在改名 FlasCC，還有開源版的 crossbridge
5.沙箱
一些本地語(yǔ)言看似很簡(jiǎn)單的操作，在沙箱里就未必如此。例如數(shù)組操作：
- vector[k] = v
虛擬機(jī)首先得檢查索引是否越界，否則會(huì)有嚴(yán)重的問題。如果「前端慢加密」算法涉及到大量?jī)?nèi)存隨機(jī)訪問，那就會(huì)有很多無(wú)意義的內(nèi)耗，因此得慎重考慮。不過有些特殊場(chǎng)合，腳本速度甚至能超過本地程序！例如開頭提到的 MD5 大量反復(fù)計(jì)算。
這其實(shí)不難解釋：
首先，MD5 算法很簡(jiǎn)單。沒有查表這樣的內(nèi)存操作，使用的都是局部變量。局部變量的位置都是固定的，避免了越界檢查開銷。其次，emscripten 的優(yōu)化能力，并不比本地編譯器差。最后，本地程序編譯之后，機(jī)器指令就不會(huì)再變了；而如今腳本引擎，都有 JIT 這個(gè)利器。它會(huì)根據(jù)運(yùn)行時(shí)的情況，實(shí)時(shí)生成更優(yōu)化的機(jī)器指令。
所以選擇加密算法時(shí)，還得兼顧實(shí)際運(yùn)行環(huán)境，揚(yáng)長(zhǎng)避短，發(fā)揮出最大功效。
0×09 對(duì)抗 GPU
眾所周知，跑密碼使用 GPU 可以快很多倍。GPU 可以想象成一個(gè)有幾百上千核的處理器，但只能執(zhí)行一些簡(jiǎn)單的指令。雖然單核速度不及 CPU，但可以通過數(shù)量取勝。暴力窮舉時(shí)，可以從字典里取出上千個(gè)詞匯同時(shí)跑，破解效率就提高了。
那能否在算法里添加一些特征，正好命中 GPU 的軟肋呢？
1.顯存瓶頸
大家聽過說「萊特幣」吧。不同于比特幣，萊特幣挖礦使用了 scrypt 算法。這種算法對(duì)內(nèi)存依賴非常大，需要頻繁讀寫一個(gè)表。GPU 雖然每個(gè)線程都能獨(dú)立計(jì)算，但顯存只有一個(gè)，大家共享使用。這意味著，同時(shí)只有一個(gè)線程能操作顯存，其他有需要的只能等待了。這樣，就極大遏制了并發(fā)的優(yōu) 勢(shì)。
2.移植難度
山寨幣遍地開花的時(shí)候，還出現(xiàn)了一個(gè)叫 X11Coin 的幣，據(jù)稱能對(duì)抗 ASIC。它的原理很簡(jiǎn)單，里面摻雜了 11 種不同的加密算法。這樣，制造出相應(yīng)的 ASIC 復(fù)雜度大幅增加了。盡管這不是一個(gè)長(zhǎng)久的對(duì)抗方案，但思路還是可以借鑒的。如果一件事過于復(fù)雜，很多攻擊者就望而生畏了，不如去做更容易到手的事。
3.其他想法
之所以 GPU 能大行其道，是因?yàn)槟壳暗募用芩惴?，都是?jiǎn)單的公式運(yùn)算。這對(duì) CPU 并沒太大的優(yōu)勢(shì)。能否設(shè)計(jì)一個(gè)算法，充分依賴 CPU 的優(yōu)勢(shì)？CPU 有很多隱藏的強(qiáng)項(xiàng)，例如流水線。如果算法中有大量的條件分支，也許 GPU 就不擅長(zhǎng)了。
當(dāng)然，這里只是設(shè)想。自己創(chuàng)造加密算法，是非常困難的，也不推薦這么做。
0x0A 額外意義
除了能降低密碼破解速度，前端慢加密還有一些其他意義：
1.減少泄露風(fēng)險(xiǎn)
用戶輸入的明文密碼，在前端內(nèi)存里就已加密。離開瀏覽器，泄露風(fēng)險(xiǎn)就已結(jié)束。即使通信被竊聽，或是服務(wù)器上的惡意中間件，都無(wú)法拿到明文密碼。除非網(wǎng)頁(yè)本身有惡意代碼，或是用戶系統(tǒng)存在惡意軟件。
2.無(wú)法私藏明文
盡管大部分網(wǎng)站都聲稱，不會(huì)存儲(chǔ)用戶的明文密碼。但這并沒有證據(jù)，也許私下里仍在悄悄儲(chǔ)存。如果在前端加密，網(wǎng)站就無(wú)法拿到用戶的明文密碼了。也許正是這一點(diǎn)，很多網(wǎng)站不愿意使用前端加密。
事實(shí)上，其實(shí)網(wǎng)站不愿意也沒關(guān)系，我們可以自己做一個(gè)單機(jī)版的慢加密插件。當(dāng)選中網(wǎng)頁(yè)密碼框時(shí)，彈出我們插件。在插件里輸入密碼后，開始慢加密計(jì)算。最后將結(jié)果填入頁(yè)面密碼框里。這樣，所有的網(wǎng)站都可以使用了。當(dāng)然，已注冊(cè)的賬號(hào)是不行的，得手動(dòng)調(diào)整一下。
3.增加撞庫(kù)成本
「前端慢加密」需要消耗用戶的計(jì)算力，這個(gè)缺點(diǎn)有時(shí)也是件好事。
對(duì)于正常用戶來(lái)說，登錄時(shí)多等一秒影響并不大。但對(duì)于頻繁登錄的用戶來(lái)說，這就是一個(gè)障礙了。誰(shuí)會(huì)頻繁登錄？也許就是撞庫(kù)攻擊者。他們無(wú)法拖下這個(gè) 網(wǎng)站的數(shù)據(jù)庫(kù)，于是就用在線登錄的方式，不斷的測(cè)試弱口令賬號(hào)。如果通過 IP 來(lái)控制頻率，攻擊者可以找大量的代理 —— 網(wǎng)速有多快，就能試多快。
但使用了前端慢加密，攻擊者每試一個(gè)密碼，就得消耗大量的計(jì)算，于是將瓶頸卡在硬件上 —— 能算多快，才能試多快。所以，這里有點(diǎn)類似 PoW（Proof-of-Work，工作量證明）的意義。關(guān)于 PoW，以后我們會(huì)詳細(xì)介紹。
0x0B 無(wú)法做到的
盡管「前端慢加密」有不少優(yōu)勢(shì)，但也不是萬(wàn)能的。上一節(jié)也提到，能減少風(fēng)險(xiǎn)，而不是消除風(fēng)險(xiǎn)。如果本地環(huán)境有問題，那任何密碼輸入都有風(fēng)險(xiǎn)。
下面我們來(lái)思考一個(gè)場(chǎng)景：某網(wǎng)站使用了「前端慢加密」，但沒有使用 HTTPS —— 這會(huì)導(dǎo)致鏈路被竊聽?；仡?0×05 小節(jié)，如果拿到「慢加密結(jié)果」，就可以直接登上賬號(hào)，即使不知道明文密碼。的確如此。但請(qǐng)仔細(xì)想一想，這不也降低損失了嗎？
本來(lái)不僅賬號(hào)被盜用，而且明文密碼也會(huì)泄露；而如今，只是賬號(hào)被盜用，明文密碼對(duì)方仍無(wú)法獲得。所以，前端慢加密的真正保護(hù)的是「密碼」而不是「賬號(hào)」。賬號(hào)被盜，密碼拿不到！
如果攻擊者不僅能竊聽，還能控制流量的話，就可以往頁(yè)面注入攻擊腳本，從而獲得明文密碼。當(dāng)然，這和電腦中毒、鍵盤偷窺一樣，都屬于「環(huán)境有問題」，不在本文討論范圍內(nèi)。本文討論的是數(shù)據(jù)庫(kù)泄露的場(chǎng)景。
0x0C 多線程慢加密
用戶的配置越來(lái)越好，不少都是四核、八核處理器。能否利用多線程的優(yōu)勢(shì)，將慢加密計(jì)算進(jìn)行分解？如果每一步計(jì)算都依賴之前的結(jié)果，是無(wú)法進(jìn)行拆解的。例如：
- for i = 0 ~ 10000
- x = hash(x)
- end
這是一個(gè)串行的計(jì)算。然而只有并行的問題，才能分解成多個(gè)小任務(wù)。不過，換一種方式的多線程也是可以的。例如我們使用 4 個(gè)線程：
- # 線程 1
- x1 = hash(password + "salt1")
- for i = 0 ~ 2500
- x1 = hash(x1)
- end
- # 線程 2
- x2 = hash(password + "salt2")
- for i = 0 ~ 2500
- x2 = hash(x2)
- end
- # ...
最終將 4 個(gè)結(jié)果合并起來(lái)，再做一次加密，作為慢加密結(jié)果。但這樣會(huì)導(dǎo)致更容易破解嗎？留著給大家思考。
0x0D 總結(jié)
前端慢加密，就是讓每個(gè)用戶貢獻(xiàn)少量的計(jì)算資源，使加密變得更強(qiáng)勁。即使數(shù)據(jù)泄露，其中也凝聚了全網(wǎng)站用戶的算力，從而大幅增加破解成本。
0xFF 后記
前些年比特幣流行時(shí)，突發(fā)奇想用瀏覽器來(lái)挖礦。雖然沒做成，不過獲得了一些密碼學(xué)姿勢(shì)。近期重新進(jìn)行了整理，并添加了一些新想法，于是寫篇詳細(xì)的文章分享一下。因?yàn)槊艽a學(xué)屬于傳統(tǒng)領(lǐng)域，所以結(jié)合當(dāng)下流行的 Web 技術(shù)，才能更有新意。
如果你對(duì)算法有疑惑，可以先仔細(xì)看 0×05 這節(jié)。
如果你是耐心看完本文的，希望能有收獲: )
本文名稱：對(duì)抗拖庫(kù)——Web前端慢加密
文章網(wǎng)址：http://www.dlmjj.cn/article/djidjho.html
