同事在群里甩過來一份內(nèi)部自查報(bào)告說系統(tǒng)里還有一批賬號的密碼強(qiáng)度不達(dá)標(biāo)需要我做一次密碼安全審計(jì)。我當(dāng)時(shí)手上能用的工具就一個(gè)john。很多人第一次聽到“john 破解用戶密碼”這個(gè)說法第一反應(yīng)會往歪處想但實(shí)際在一線做安全運(yùn)維john the ripper 這類工具用得最多的場景恰恰是自查——給自己管的服務(wù)器、自己負(fù)責(zé)的業(yè)務(wù)系統(tǒng)、自己交付給客戶的加密文件做一次強(qiáng)度體檢看看哪些口令能在幾分鐘內(nèi)被字典跑出來然后把它們換掉。真正危險(xiǎn)的不是工具而是你從來不知道自己系統(tǒng)的密碼到底有多脆。這篇內(nèi)容就是把我這些年用 john 做密碼審計(jì)和配套防破解加固的完整流程拆開講一遍包括安裝避坑、哈希識別、字典與規(guī)則調(diào)優(yōu)、ZIP 壓縮包密碼自查以及更重要的那半邊怎么讓你的密碼體系扛得住同類工具的沖擊。適合安全運(yùn)維、后端開發(fā)、運(yùn)維工程師以及需要給自己產(chǎn)品或交付物做安全加固的從業(yè)者參考基礎(chǔ)薄弱的朋友也能照著走一遍。1. 先搞清楚 john 到底在破解什么1.1 哈希不是密碼破解的本質(zhì)是比對新手最容易卡住的點(diǎn)是把“破解密碼”想象成某種能直接讀出明文的魔法。實(shí)際不是?，F(xiàn)代系統(tǒng)里存的基本都是口令的散列值john 拿到的輸入通常長這樣admin:$6$kH9x...$3fA1bZ...:1000:1000:Admin:/home/admin:/bin/bash冒號后面那一串才是它真正處理的東西。john 的工作流程非常樸素——按某種策略生成候選口令用同樣的算法算出散列值再跟目標(biāo)散列值逐字節(jié)比對命中即停。所以它的速度上限并不取決于算法多聰明而取決于兩件事候選口令的生成效率以及單位時(shí)間內(nèi)能做多少次哈希運(yùn)算。理解這一點(diǎn)之后很多后來的困惑就自動(dòng)解開了。為什么字典文件質(zhì)量決定成敗因?yàn)楹蜻x池里沒有正確答案跑一萬年也沒用。為什么同一個(gè)口令在不同系統(tǒng)上被跑出來的時(shí)間差幾十倍因?yàn)?SHA-512 迭代輪數(shù)、bcrypt 的 cost 因子、內(nèi)存硬算法帶來的成本完全不同。為什么顯卡比 CPU 快那么多因?yàn)楣＿\(yùn)算高度并行而 GPU 的核心數(shù)量是 CPU 的幾十上百倍。我在實(shí)際項(xiàng)目里見過最典型的誤判就是有人拿一堆 MD5 歷史庫去套現(xiàn)代系統(tǒng)發(fā)現(xiàn)跑不出來就覺得 john 沒用。其實(shí)是對手從 MD5 換成了 bcrypt難度差了好幾個(gè)數(shù)量級工具沒問題是目標(biāo)變了。1.2 三種模式對應(yīng)三種完全不同的思路john 的模式選擇不是隨便挑的每種模式背后是一套假設(shè)你在什么場景下用哪種模式取決于你對目標(biāo)口令的了解程度。單模式Single假設(shè)的是“用戶圖省事口令跟自己的賬號信息有關(guān)”。它會拿用戶名、家目錄、GECOS 字段里的信息做變形組合。這個(gè)模式最大的價(jià)值是快——通常幾秒鐘就能跑完一輪而且命中率出乎意料地高。很多企業(yè)內(nèi)網(wǎng)里zhangsan2024、liwei123這類口令就是被這個(gè)模式秒破的。字典模式Wordlist是最常用的。它把字典文件里的每一行當(dāng)候選配合規(guī)則引擎做變形。它的核心變量只有兩個(gè)字典的覆蓋范圍和規(guī)則的想象力。這兩個(gè)變量的可調(diào)空間非常大后面我會單獨(dú)拿一章講。增量模式Incremental是窮舉按字符集逐步爆破從短到長。它是最后手段因?yàn)闀r(shí)間成本呈指數(shù)增長。但它的好處是不依賴任何字典質(zhì)量純靠算力和時(shí)間硬堆。我在實(shí)操里的順序固定是先 Single 跑一遍幾十秒再 Wordlist 加規(guī)則幾小時(shí)量級最后才考慮 Incremental。絕大多數(shù)真實(shí)場景在前兩步就結(jié)束了直接上 Incremental 是新手最常見的資源浪費(fèi)。1.3 它能做和它做不到的邊界把邊界劃清楚能省掉大量試錯(cuò)。john 能做的是識別上百種哈希格式、處理多種加密容器的提取文件、支持規(guī)則變形、支持增量窮舉、支持會話保存與恢復(fù)、支持多種加速后端。john 做不到的是繞過加鹽salt 會顯著增加成本但理論上仍可爆破、繞過強(qiáng)算法Argon2、高 cost 的 bcrypt 在合理口令面前基本無解、繞過非密碼保護(hù)機(jī)制比如雙因素、硬件密鑰、繞過訪問控制它處理的是離線文件不是在線爆破。注意john 處理的是“離線樣本”。它不能登錄任何系統(tǒng)也不做網(wǎng)絡(luò)請求。這一點(diǎn)決定了它的合規(guī)邊界——你可以用它審計(jì)你手里有權(quán)查看的哈希文件但拿到別人的哈希文件本身就是另一回事了。2. 安裝與環(huán)境準(zhǔn)備的那些坑2.1 版本路線怎么選john 有兩條主要的版本路線很多人卡在第一步就是因?yàn)檠b錯(cuò)了版本還不知道。一條是社區(qū)版俗稱 jumbo 之外的經(jīng)典版本功能相對基礎(chǔ)格式支持較少勝在穩(wěn)定、編譯簡單。另一條是社區(qū)增強(qiáng)版通常叫 jumbo支持格式擴(kuò)展到了上百種包括各種文檔格式、容器格式的提取工具比如專門處理壓縮包的那個(gè)輔助程序規(guī)則引擎也更完整。我的建議很直接做安全審計(jì)就用增強(qiáng)版。理由不是它“更強(qiáng)”而是它自帶了一整套格式提取輔助程序你不用自己去寫腳本解析文件頭。少寫一個(gè)解析器就少一個(gè)出錯(cuò)點(diǎn)。增強(qiáng)版官方提供的是源碼包需要自己編譯。編譯前要確認(rèn)系統(tǒng)里有 C 編譯器、make以及幾個(gè)可選依賴庫。如果打算用 OpenMP 多線程還要確認(rèn)編譯器支持并打開對應(yīng)開關(guān)。缺依賴不會導(dǎo)致編譯失敗而是會靜默降級——你跑起來發(fā)現(xiàn)只用了一個(gè)核心性能差一大截還以為是硬件問題。我在第一次編譯時(shí)踩的坑就是沒裝 OpenMP 開發(fā)包跑了一晚上才發(fā)現(xiàn) CPU 占用只有 12%單核在跑。后來重新編譯打開開關(guān)同樣的任務(wù)時(shí)間直接掉了三分之二。2.2 各平臺的落地方式不同系統(tǒng)上的處理方式差異不小我按我實(shí)際用過的排序說。在主流 Linux 發(fā)行版上官方源里有基礎(chǔ)版本裝起來一條命令就行但功能比較有限。如果要增強(qiáng)版就下載源碼包解壓進(jìn)去之后先跑配置腳本再編譯最后把生成的可執(zhí)行文件和它依賴的輔助程序放到一個(gè)統(tǒng)一目錄里。整個(gè)過程在三十分鐘內(nèi)能搞定前提是依賴沒缺。在 macOS 上要注意兩點(diǎn)一是系統(tǒng)自帶的編譯工具鏈要先裝好二是如果用 ARM 架構(gòu)的機(jī)器部分加速后端需要額外配置否則會退回純 CPU 模式。我在 M 系列芯片上編譯時(shí)最開始沒指定架構(gòu)參數(shù)結(jié)果跑出來的二進(jìn)制性能明顯不對勁重新編譯后正常了。在 Windows 上官方提供了預(yù)編譯包解壓即用但它默認(rèn)只有基礎(chǔ)格式支持。我的經(jīng)驗(yàn)是 Windows 上更適合做基礎(chǔ)的哈希處理和學(xué)習(xí)用途真要做大規(guī)模審計(jì)還是放到 Linux 環(huán)境腳本化和批處理都方便太多。2.3 裝完先做三件事裝完之后千萬別急著丟文件進(jìn)去跑。先做三步自檢能避免后面大量無效等待。第一確認(rèn)可執(zhí)行文件能正常輸出幫助信息這一步是確認(rèn)動(dòng)態(tài)庫鏈接沒問題。第二確認(rèn)輔助程序目錄的路徑正確。增強(qiáng)版的格式提取工具通常在一個(gè)子目錄里如果你不在那個(gè)目錄下執(zhí)行或者沒有把它加入環(huán)境變量就會遇到“命令找不到”的問題而這不是程序壞了。第三做一次性能基線測試。用一個(gè)小字典跑一個(gè)你自己造的測試哈?？纯疵棵雵L試次數(shù)在什么量級。這個(gè)數(shù)字是你后面判斷“加速是否生效”的基準(zhǔn)線。我一般會記錄 CPU 單核、多核、以及是否啟用 GPU 三種情況下的數(shù)字方便后續(xù)對比。提示把這三個(gè)數(shù)字記在一個(gè)文本文件里跟項(xiàng)目記錄放在一起。下次換機(jī)器或者改了編譯參數(shù)直接對比就能知道有沒有回退。3. 拿到哈希才是真正的起點(diǎn)3.1 從系統(tǒng)影子文件里取樣本這是最經(jīng)典的場景。系統(tǒng)的賬號信息分兩處存放用戶基本信息在一處口令散列在另一處且權(quán)限很嚴(yán)格。john 增強(qiáng)版自帶了一個(gè)合并工具可以把兩者合成它需要的格式。合成之后的文件里每一行包含賬號名和散列值。這個(gè)時(shí)候先別急著跑先把散列算法分類統(tǒng)計(jì)一下。同一個(gè)文件里往往混著好幾種算法——老賬號可能是舊格式新賬號是新格式而它們的破解難度天差地別。散列前綴對應(yīng)算法抗爆破強(qiáng)度$1$MD5 系很弱基本秒破$5$SHA-256 系中等依賴迭代輪數(shù)$6$SHA-512 系中等偏上依賴迭代輪數(shù)$2a$/$2b$bcrypt強(qiáng)依賴 cost 因子$y$yescrypt強(qiáng)$argon2$Argon2 系強(qiáng)內(nèi)存硬這張表是我每次做審計(jì)的第一步篩查依據(jù)。如果統(tǒng)計(jì)下來大部分是$6$或者$2b$那這次審計(jì)的重點(diǎn)就不是“能不能破”而是“多久能破”以及“口令長度分布是否合理”。如果統(tǒng)計(jì)里還有大量$1$那這就是一個(gè)明確的整改項(xiàng)跟口令本身強(qiáng)弱已經(jīng)無關(guān)了。3.2 哈希格式識別與手動(dòng)指定john 的自動(dòng)識別能力不錯(cuò)但它不是萬能的。遇到識別不了的情況你需要手動(dòng)指定格式否則它會跑一套錯(cuò)誤的算法然后告訴你“跑完了零命中”——最坑的就是這種靜默失敗。手動(dòng)指定的方法是在命令里加上格式參數(shù)。格式名怎么查用官方的格式列表參數(shù)會輸出一長串支持的格式名和對應(yīng)的示例散列。我的做法是先自動(dòng)跑一次觀察它的運(yùn)行信息里顯示的格式名如果沒顯示或者明顯不對再手動(dòng)指定。有一個(gè)很容易忽略的細(xì)節(jié)從某個(gè)容器里提取出來的散列值和系統(tǒng)影子文件里的散列值格式可能是一樣的但提取工具為了讓 john 能認(rèn)出來會在散列前面加一個(gè)特定的標(biāo)識前綴。這些前綴是提取工具生成的不是原始數(shù)據(jù)的一部分。如果你手動(dòng)編輯過提取出來的文件把這些前綴刪掉了john 就可能識別不出來。3.3 壓縮包密碼的自查流程這條是很多人的實(shí)際需求也是搜索里出現(xiàn)頻率很高的場景自己很久以前打包的壓縮包密碼想不起來了或者要驗(yàn)證一下交付給客戶的加密包強(qiáng)度夠不夠。流程分兩步。第一步是用配套的提取工具把壓縮包里的加密校驗(yàn)信息抽出來輸出成一個(gè)文本文件。這個(gè)文件里就是壓縮包密碼對應(yīng)的散列值。第二步才是把這個(gè)文件交給 john 跑。第一步的實(shí)現(xiàn)方式很直白就是在命令行里調(diào)用提取工具指定壓縮包路徑把輸出重定向到文件。這里要注意有些壓縮包內(nèi)部包含多個(gè)加密條目提取出來的文件會有多行這屬于正?，F(xiàn)象john 會逐行處理。第二步跑的時(shí)候關(guān)鍵參數(shù)是字典和規(guī)則。這里有個(gè)真實(shí)經(jīng)驗(yàn)壓縮包密碼在現(xiàn)實(shí)中往往比系統(tǒng)口令更“聰明”一點(diǎn)因?yàn)槿嗽O(shè)壓縮包密碼的時(shí)候通常知道它是自己用的會設(shè)得長一些。所以單純跑一個(gè)大路貨字典命中率不高配合規(guī)則變形才是正解。我個(gè)人的經(jīng)驗(yàn)是如果對方是人為主觀設(shè)定的密碼包含日期、姓名縮寫變形的概率很高規(guī)則引擎里要專門打開針對這類變形組合的規(guī)則集。跑出來之后john 會把結(jié)果存在它自己的結(jié)果文件里下次查看用展示參數(shù)即可不需要重新跑。這個(gè)記錄文件是純文本可以隨時(shí)導(dǎo)出整理。3.4 文檔與容器格式的通用套路除了壓縮包還有幾類特別常見PDF、辦公文檔、以及某些數(shù)據(jù)庫的憑據(jù)容器。它們的處理套路是一致的先用對應(yīng)的提取工具把加密參數(shù)抽出來再交給 john。這里有一個(gè)跨格式的通用注意點(diǎn)提取工具的輸出質(zhì)量和 john 的版本強(qiáng)相關(guān)。新版 john 支持的格式多但提取工具可能對某些新版本文檔格式支持不完整。比如某個(gè)辦公文檔套件的新格式用舊版提取工具抽出來的散列可能是空的或者抽出來但 john 識別不了。這種情況下別硬剛。我的處理辦法是先用文檔自身的命令行工具把文件降級保存成老格式再提取。多數(shù)情況下問題就解決了。這個(gè)技巧在看文檔里是找不到的純靠踩坑積累。3.5 命令行參數(shù)怎么控制效率參數(shù)用對了同樣的硬件能省一半時(shí)間。我固定會看這幾個(gè)維度。并發(fā)控制默認(rèn)情況下 john 會盡量用滿可用核心。如果你在共享服務(wù)器上跑記得限制并發(fā)數(shù)別把生產(chǎn)環(huán)境的 CPU 跑滿。這個(gè)參數(shù)在 john 的選項(xiàng)里可以直接指定。會話管理長任務(wù)一定要用會話參數(shù)保存進(jìn)度中途中斷可以用恢復(fù)參數(shù)接著跑不用從頭來。我吃過一次虧跑了十幾個(gè)小時(shí)的增量任務(wù)機(jī)器重啟全沒了只能重來。結(jié)果查看和清理查看用展示參數(shù)清理用重置參數(shù)。這兩個(gè)操作我看很多人搞混——如果你只想看結(jié)果千萬不要?jiǎng)佑涗浳募坏┱`刪已經(jīng)跑出來的結(jié)果就沒了而且 john 不會重新記錄。注意跑任何長時(shí)間任務(wù)之前先用一個(gè)小字典做一輪完整測試確認(rèn)參數(shù)、字典路徑、輸出路徑全對。五分鐘的測試能省掉十小時(shí)的返工。4. 字典、規(guī)則與增量把效率拉滿4.1 字典的清洗比收集更重要新手最愛干的事是到處收集字典包幾十個(gè) G 拼在一起。我早期也這么干效果很差。原因很簡單字典是按“命中概率”排序才有價(jià)值的你拼成一坨john 從里面順序讀前面幾百萬條垃圾條目把時(shí)間全耗光了。正確做法是先做去重和清洗再去掉明顯不適用的部分。我這里有幾個(gè)固定步驟去重、去掉純數(shù)字的超長序列這些交給增量模式更高效、把跟目標(biāo)環(huán)境相關(guān)的詞匯前置。所謂“跟目標(biāo)環(huán)境相關(guān)”指的是項(xiàng)目名、公司名、產(chǎn)品名、縮寫、常見拼音組合、年份組合。這一步的效果是決定性的。我在一次內(nèi)部審計(jì)里標(biāo)準(zhǔn)大字典跑了兩小時(shí)零命中把我整理的環(huán)境相關(guān)詞匯放到前面重跑十七分鐘出了六個(gè)結(jié)果。還有一個(gè)容易被忽略的點(diǎn)字典文件的編碼。如果你的系統(tǒng)環(huán)境是 UTF-8而字典文件是別的編碼某些字符會被錯(cuò)誤解析導(dǎo)致候選口令失真。這個(gè)錯(cuò)誤非常隱蔽因?yàn)槌绦虿粫?bào)錯(cuò)只是安靜地少跑一些候選。4.2 規(guī)則引擎才是真正的放大器字典模式如果只是原樣讀每一行那它的能力上限就是字典本身。規(guī)則引擎的作用是把每一條基礎(chǔ)詞做變形一變十、十變百。常用的變形維度包括大小寫切換、首字母大寫、末尾加數(shù)字、末尾加常見符號、數(shù)字替換字母比如用 0 替 o用 1 替 i、前后加年份、重復(fù)拼接、常見大小寫混寫模式。這些變形的組合數(shù)量可以很輕松地到幾萬倍。規(guī)則集的用法很靈活。你可以用內(nèi)置的規(guī)則集也可以自己寫規(guī)則文件。我遇到需要針對性審計(jì)的場景比如某個(gè)部門的口令風(fēng)格有固定規(guī)律就會專門寫一個(gè)精簡規(guī)則集把命中率最高的變形排在前面。這里有一個(gè)必須知道的事實(shí)規(guī)則越多單條基礎(chǔ)詞的處理時(shí)間越長。全量規(guī)則跑一遍一個(gè)上百萬條的字典時(shí)間成本可能是一天以上。所以我的策略是分級先用輕量規(guī)則快速過一遍再上重量規(guī)則最后才是增量。階段策略預(yù)期時(shí)間說明第一輪單模式秒到分鐘用賬號信息變形第二輪精簡字典 輕量規(guī)則十分鐘到一小時(shí)高頻口令第三輪完整字典 完整規(guī)則幾小時(shí)到一天主流規(guī)律覆蓋第四輪增量模式天到周兜底看投入產(chǎn)出這張表是我做任何一次審計(jì)前都會先擬出來的時(shí)間預(yù)算。擬不出來就別開跑因?yàn)榕艿揭话肽銜萑搿耙灰！钡募m結(jié)。4.3 增量模式與加速后端增量模式需要設(shè)定字符集和長度范圍。字符集越大、長度上限越高搜索空間越大。這里有一個(gè)簡單但很多人算錯(cuò)的賬搜索空間是字符集大小的長度次方。字符集擴(kuò)一倍長度加一搜索空間就是幾倍到十幾倍的差距。所以我用增量模式的策略永遠(yuǎn)是“先窄后寬”先用數(shù)字加小寫字母跑短長度再擴(kuò)展到包含大寫和符號長度上限一點(diǎn)點(diǎn)往上加。同時(shí)開啟會話保存因?yàn)樵隽咳蝿?wù)幾乎不可能一次跑完。關(guān)于加速后端核心邏輯是哈希運(yùn)算可以被高度并行化而 GPU 的核心數(shù)量遠(yuǎn)超 CPU。約翰的增強(qiáng)版支持多種加速后端配置正確的情況下能帶來數(shù)量級的提升。但配置本身有門檻涉及驅(qū)動(dòng)、運(yùn)行庫版本匹配而且只對部分哈希類型有明顯收益——內(nèi)存硬算法在 GPU 上優(yōu)勢會被削弱因?yàn)轱@存帶寬和容量成為新瓶頸。我的建議是分兩步走先把 CPU 多線程這條路走通、性能基線測出來確保流程跑得通再考慮上 GPU。順序反了的話你會在驅(qū)動(dòng)問題上耗掉大量時(shí)間而且分不清是工具問題還是配置問題。4.4 時(shí)間成本與投入產(chǎn)出怎么算這是整個(gè)流程里最沒有標(biāo)準(zhǔn)答案但最需要判斷力的部分。我一般用三個(gè)指標(biāo)做決策。第一是覆蓋率當(dāng)前策略能覆蓋候選空間的比例。第二是單位時(shí)間命中數(shù)每跑一小時(shí)能出幾個(gè)結(jié)果。第三是整改成本如果這一批口令破不出來直接強(qiáng)制重置的成本有多大。實(shí)操中當(dāng)命中曲線明顯走平——比如跑了三小時(shí)只多出一個(gè)結(jié)果——就該停了。剩下的那部分口令從防御角度看反而是好消息說明它們已經(jīng)足夠強(qiáng)。這時(shí)候正確動(dòng)作是拿著已經(jīng)破出來的弱口令清單去推動(dòng)整改而不是硬啃剩下那部分。我見過太多人把審計(jì)做成了純粹的算力比拼跑了一周出來兩個(gè)結(jié)果報(bào)告寫得像軍功章。但審計(jì)的目的是改進(jìn)不是炫技。能在一小時(shí)內(nèi)找出二十個(gè)弱口令并讓它們被換掉價(jià)值遠(yuǎn)高于一周找出一個(gè)。5. 防破解讓同類工具在你的系統(tǒng)上效率歸零5.1 口令本身怎么設(shè)才有實(shí)際意義所有加固措施里口令長度是性價(jià)比最高的一項(xiàng)。原因很簡單搜索空間的增長速度是指數(shù)級的而人腦記憶的舒適區(qū)是線性的。長度每加一位破解成本就上一個(gè)臺階而多記兩位對多數(shù)人來說并不困難。我的經(jīng)驗(yàn)閾值是普通業(yè)務(wù)賬號至少 12 位管理員級賬號至少 16 位。低于這個(gè)長度無論字符集多復(fù)雜在現(xiàn)代硬件面前都撐不了太久。第二重要的是避免可預(yù)測的結(jié)構(gòu)。很多人以為把常見詞加幾個(gè)符號就安全了其實(shí)規(guī)則引擎專門處理這種變形。真正有效的是使用互不相關(guān)的多個(gè)詞組合或者用一句只有你自己知道的話取首字母加特殊處理。這種口令的搜索空間遠(yuǎn)大于“單詞加數(shù)字”。第三是唯一性。同一個(gè)口令復(fù)用在多個(gè)系統(tǒng)上一次泄露就是全線失守。這一點(diǎn)在審計(jì)中最容易暴露——我經(jīng)常在同一個(gè)組織的一批賬號里看到高度相似的口令模式一次規(guī)則變形就能連著命中七八個(gè)。提示判斷一個(gè)口令強(qiáng)不強(qiáng)最直接的辦法就是把它對應(yīng)的散列值丟給 john 跑一輪。跑不出來就是及格跑出來了就換。這個(gè)方法比任何強(qiáng)度評分算法都實(shí)在。5.2 存儲層加固算法和參數(shù)的選擇同樣的口令用不同的算法存抗爆破能力可以差幾個(gè)數(shù)量級。這是防御端最容易被忽略、但收益最大的一環(huán)。核心原則是選擇有意設(shè)計(jì)成“慢”的算法?？焖偕⒘兴惴ū热?MD5、SHA 系列的單輪版本的設(shè)計(jì)目標(biāo)是計(jì)算快這對防御方是災(zāi)難。而專門為口令設(shè)計(jì)的算法會通過迭代輪數(shù)、內(nèi)存占用、并行度限制來抬高單次計(jì)算成本。具體選擇上能上內(nèi)存硬算法就上。它們的特性是需要大量內(nèi)存才能計(jì)算這讓 GPU 并行優(yōu)勢大幅削弱因?yàn)轱@存容量是硬約束。次優(yōu)選擇是高 cost 的 bcryptcost 每加一計(jì)算成本翻倍。這里有一個(gè)必須注意的實(shí)操細(xì)節(jié)算法升級之后老賬號的散列值還在用舊算法。有兩種處理方式一是在用戶下次登錄時(shí)用新算法重新計(jì)算并替換二是強(qiáng)制批量重置。前者體驗(yàn)好后者更徹底。我傾向于前者但對管理員賬號做后者。還有一個(gè)常被忽視的點(diǎn)是加鹽。鹽值的作用是讓相同口令產(chǎn)生不同散列直接廢掉預(yù)計(jì)算表?，F(xiàn)代算法默認(rèn)都帶鹽但如果你在自研系統(tǒng)里手動(dòng)實(shí)現(xiàn)過散列邏輯一定要確認(rèn)鹽是隨機(jī)生成的、每個(gè)用戶獨(dú)立、并且長度足夠。5.3 系統(tǒng)層把在線試錯(cuò)的路堵死所有前面的加固針對的都是“離線樣本被拿到”的情況。還有另一條路是攻擊者直接在線試密碼。這條路要靠系統(tǒng)策略來堵。第一是速率限制和賬號鎖定。失敗的嘗試次數(shù)達(dá)到閾值后賬號臨時(shí)鎖定或登錄延遲遞增。這個(gè)機(jī)制的參數(shù)要調(diào)好閾值太低會導(dǎo)致服務(wù)臺工單暴增閾值太高等于沒有。我的經(jīng)驗(yàn)是配合遞增延遲使用比硬性鎖定體驗(yàn)好同時(shí)依然能有效壓制自動(dòng)化的高頻嘗試。第二是日志和告警。失敗嘗試要記錄來源、賬號、時(shí)間并且對同一賬號的連續(xù)失敗、或同一來源對多個(gè)賬號的失敗嘗試觸發(fā)告警。這個(gè)信號的準(zhǔn)確率很高誤報(bào)主要集中在用戶改密碼之后忘了更新憑據(jù)的場景很好排查。第三是提高認(rèn)證因子的數(shù)量?？诹钭鳛閱我灰蜃颖举|(zhì)上就是在賭用戶會設(shè)一個(gè)足夠長的口令。加一個(gè)非口令因子破解的意義直接下降一個(gè)維度。5.4 加密文件與壓縮包的防破解這一塊經(jīng)常被忽略但實(shí)際風(fēng)險(xiǎn)很實(shí)在。交付給外部的加密包如果密碼設(shè)得隨意對方拿到包之后跑一輪字典就開了里面的內(nèi)容等于明文外發(fā)。我的固定做法有三條。密碼長度上加密文件的密碼我用的是跟管理員賬號同級別的標(biāo)準(zhǔn)因?yàn)樗氖褂妙l率低不需要考慮輸入體驗(yàn)。密碼來源上不用人腦想的詞而是從隨機(jī)源生成用密碼管理器保存通過安全渠道單獨(dú)傳遞。加密算法上打包時(shí)選擇支持強(qiáng)加密的選項(xiàng)不要用老式的弱加密方案。這里有一個(gè)實(shí)操細(xì)節(jié)值得單獨(dú)提某些打包工具的默認(rèn)加密選項(xiàng)可能是兼容性優(yōu)先的老算法。你要在設(shè)置里手動(dòng)切換到強(qiáng)加密而且要注意有些工具在命令行模式下默認(rèn)值和圖形界面下的默認(rèn)值不一樣。我踩過這個(gè)坑——圖形界面里選了強(qiáng)加密腳本調(diào)用時(shí)用的是默認(rèn)值出來的包強(qiáng)度完全不同。驗(yàn)證方式也很直接包做完之后用提取工具把校驗(yàn)信息抽出來自己跑一輪短字典。跑不出來才交付。這個(gè)自檢動(dòng)作花五分鐘能擋掉絕大部分低級失誤。5.5 制度層把自查變成常態(tài)技術(shù)措施不配合制度很容易腐化。我參與過的比較有效的做法是固定的季度自查抽一批賬號的散列值用統(tǒng)一的時(shí)間預(yù)算跑一輪把能破出來的口令列成清單推動(dòng)責(zé)任人重置。同時(shí)把“口令強(qiáng)度”納入交付前的檢查項(xiàng)。自查節(jié)奏上我建議不要搞太頻繁季度一次比較合適。頻率太高跑出來的都是剛換的口令價(jià)值不大頻率太低問題積累太多整改阻力大。還有一點(diǎn)自查結(jié)果本身是敏感信息。哪些賬號口令弱、弱到什么程度這份清單的敏感度不亞于口令本身。存儲、傳遞、銷毀都要有明確規(guī)則用完即刪是最省事的做法。6. 常見問題排查與避坑速查6.1 典型故障對照表下面這些是我這些年遇到頻率最高的問題按現(xiàn)象分類整理?，F(xiàn)象可能原因處理方向跑完全程零命中格式識別錯(cuò)誤靜默用了錯(cuò)誤算法手動(dòng)指定格式參數(shù)觀察運(yùn)行信息只有單個(gè)核心在跑編譯時(shí)未啟用多線程支持重新編譯并打開對應(yīng)開關(guān)提取工具提示找不到命令未切換到增強(qiáng)版的輔助程序目錄進(jìn)入對應(yīng)目錄執(zhí)行或配置環(huán)境變量提取出來的散列文件為空文件格式版本過新提取工具不支持用工具自身的命令行降級導(dǎo)出后再提取長任務(wù)中斷后無法續(xù)跑未使用會話參數(shù)下次加會話參數(shù)用恢復(fù)參數(shù)續(xù)跑結(jié)果文件里沒有記錄誤用了重置參數(shù)或結(jié)果文件被清理保留結(jié)果文件查看只用展示參數(shù)特定編碼的字典命中異常低字典文件編碼與運(yùn)行環(huán)境不一致統(tǒng)一轉(zhuǎn)成 UTF-8 后重試加速后端啟用后性能沒變化驅(qū)動(dòng)或運(yùn)行庫版本不匹配或算法不適合核對版本先回歸 CPU 多線程基線6.2 提升效率的幾個(gè)實(shí)戰(zhàn)心得第一條心得是排序。把字典按命中概率排序而不是按字母序。這個(gè)動(dòng)作不需要任何工具但效果顯著。我通常把環(huán)境相關(guān)詞匯、常見弱口令、年份組合放到最前面。第二條心得是分段跑。不要一次性把規(guī)則開滿分成輕、中、重三輪。第一輪跑完之后看命中分布如果前一千條就命中了 80%說明這個(gè)環(huán)境的口令強(qiáng)度整體偏低后續(xù)輪次可以縮短時(shí)間如果跑了很久才零星命中說明剩下的是硬骨頭早點(diǎn)停手去推整改更劃算。第三條心得是先小規(guī)模驗(yàn)證。任何新字典、新規(guī)則集、新參數(shù)組合都先用一個(gè)包含已知答案的小樣本驗(yàn)證。確認(rèn)流程正確之后再上真實(shí)數(shù)據(jù)。這一步看起來多余但能擋住大量“跑了十小時(shí)才發(fā)現(xiàn)參數(shù)寫錯(cuò)”的事故。第四條心得是記錄。每次審計(jì)都把字典版本、規(guī)則集、運(yùn)行時(shí)長、命中數(shù)量記下來。幾次之后你就能看出這個(gè)環(huán)境的口令強(qiáng)度趨勢也能估算下一次需要多少時(shí)間預(yù)算。經(jīng)驗(yàn)數(shù)據(jù)比任何理論估算都準(zhǔn)。6.3 合規(guī)前提不能含糊這是最后一條也是最重要的一條。john 這類工具的正當(dāng)使用場景非常明確對自己擁有管理權(quán)限的系統(tǒng)做安全自查對客戶委托范圍內(nèi)的資產(chǎn)做授權(quán)評估對自己創(chuàng)建的加密文件做強(qiáng)度驗(yàn)證。這三個(gè)場景之外任何形式的嘗試都不在討論范圍內(nèi)。在實(shí)操層面我給自己定的規(guī)矩是三條一是所有審計(jì)對象必須有明確的書面授權(quán)或所有權(quán)證明二是審計(jì)過程中產(chǎn)生的所有中間文件提取出來的散列文件、跑出來的明文清單在任務(wù)結(jié)束后徹底清除三是審計(jì)報(bào)告只呈現(xiàn)統(tǒng)計(jì)結(jié)論和整改建議不附完整明文清單需要明細(xì)的單獨(dú)走加密通道交付給指定責(zé)任人。這三條不是為了應(yīng)付流程而是因?yàn)槲易约阂娺^因?yàn)槲募芾聿划?dāng)導(dǎo)致的二次事故。審計(jì)數(shù)據(jù)的安全等級不低于原始數(shù)據(jù)這一點(diǎn)怎么強(qiáng)調(diào)都不過分。這幾年下來我最大的體會是john 的價(jià)值從來不在“破”這個(gè)動(dòng)作上而在于它把“密碼到底有多弱”這件事從主觀判斷變成了可以量化的結(jié)論。以前跟業(yè)務(wù)方說“你這個(gè)密碼強(qiáng)度不夠”對方會說“我覺得挺復(fù)雜的”現(xiàn)在把散列值丟進(jìn)去跑二十分鐘出一份命中清單對方第二天就改完了。工具的說服力就在這兒。另一個(gè)反復(fù)驗(yàn)證的結(jié)論是防御端投入產(chǎn)出比最高的永遠(yuǎn)是那幾件樸素的事把口令拉長、把算法換慢、把在線試錯(cuò)限速、把加密文件的密碼當(dāng)管理員密碼對待。這些做完了再花哨的破解工具在你面前都只能干瞪眼。反過來如果這幾件基礎(chǔ)的事沒做指望靠某個(gè)高級防護(hù)方案兜底那就是把房子蓋在沙子上。如果你準(zhǔn)備上手做第一輪自查我的建議是從一小批測試賬號開始把單模式、字典加規(guī)則、增量這三條路的完整流程各走一遍把時(shí)間基線和命中率記下來。等流程順了再上真實(shí)規(guī)模。別一上來就跑全量那樣大概率是搭進(jìn)去一整天拿到一份看不懂的結(jié)果。