John the Ripper圈子里一般直接叫它 John是密码审计这件事上绕不开的一个老牌工具。它最早在 1996 年由 Openwall 项目的 Solar Designer 发布最初只针对 Unix 系统的口令文件后来演化出社区维护的 jumbo 分支支持的哈希格式一口气堆到了几百种从 Linux 的 sha512crypt、Windows 的 NTLM到各种数据库、压缩包、办公文档的加密结构基本都能吃。很多人一听到密码破解四个字就下意识往灰色地带联想其实 John 的主战场是防御方系统管理员用它给自己服务器上的口令做一次强度体检运维用它审计外包系统残留的弱口令开发者用它验证自己的加盐和迭代参数够不够硬。它解决的核心问题就一句话——你自以为很安全的密码到底扛不扛得住字典和规则的轮番冲击。这篇文章适合安全入门的新手、负责系统加固的运维以及想搞清楚密码存储原理的后端开发者。全程只以本地自建测试环境和自有数据为对象讲清楚原理、实操和防御思路不涉及任何越界场景。1. 为什么密码审计绕不开 John1.1 密码存储的真相所谓破解其实是在猜哈希先把一个容易误解的点说透。服务器上从来不保存你的明文密码它保存的是密码经过某种单向函数运算后的结果也就是哈希值。这个函数的特点是正向计算很快反向推算极难——给定一个密码算哈希眨眼的功夫给定一个哈希想还原密码理论上只能靠穷举。所以 John 干的事情本质上是猜测 验证的循环它不断生成候选密码对每个候选做同样的哈希运算再和你提供的目标哈希比对一旦对上了就说明猜中了。这个过程完全没有攻破算法的玄学成分纯粹是算力和候选质量的比拼。理解了这一点很多现象就顺理成章了。为什么同一个密码在不同机器上哈希值长得完全不一样因为绝大多数现代系统会加盐值salt——一段随机数据和密码拼在一起再算哈希。盐值让彩虹表这种预先算好海量哈希的作弊手段失效因为攻击者得针对每一个盐值重新算一遍成本瞬间抬高几个数量级。John 处理带盐哈希时会先解析出盐值再对每个候选密码套用对应的盐重新计算。这也是为什么 John 的第一步永远是识别格式格式认错了盐值解析错了后面所有计算都是白费。还有一个概念是迭代次数cost / rounds。像 bcrypt、sha512crypt、PBKDF2 这类专为密码设计的函数会故意把一次哈希运算重复几千上万次目的就是拖慢单次验证。对你登录来说多花几十毫秒无感对攻击者来说算力被硬生生稀释成千分之一。John 跑这类哈希时速度会肉眼可见地掉下来这不是它不行而是算法设计就是这么要求的。所以我常说判断一个系统密码存储做得好不好看它用的什么哈希、迭代多少轮比看它有没有加密这种模糊说法靠谱得多。1.2 John 的定位它不是黑客工具而是密码强度体检仪在安全圈里工具本身没有善恶用法才决定性质。John 被大量渗透测试团队带进授权项目干的就是我能不能在两小时内把甲方这批口令猜出来这一件事。猜得出来说明口令策略不及格该改猜不出来说明现有策略扛得住常见攻击面。这跟医生拿听诊器听心跳是一个逻辑——工具是诊断用的。它和另一个常被拿来比较的工具 Hashcat 有什么差别简单说Hashcat 更偏重 GPU 上的极限吞吐追求每秒几十亿次的算力适合大规模哈希库的批量爆破John 的优势在于格式覆盖面广、自带规则引擎和多种智能模式、开箱即用尤其适合针对少量目标做精细化的定向分析。做口令审计时我通常是先用 John 快速跑一轮字典和单字规则看看有没有low-hanging fruit低垂的果实比如用户名变形、常见年份后缀这类;真要上大规模算力才切到 Hashcat。两者不是替代关系是分工。需要把红线划清楚John 只能用在你拥有或获得明确书面授权的系统上。对别人的系统跑哈希猜测不管出于什么动机都是违法的。本文后面所有的演示都以自己生成的测试哈希为准你在自己电脑上照做跑出来的结果也只属于你自己。1.3 什么场景下该用、什么场景下碰都别碰适合用 John 的场景我列几个典型的一是新系统上线前把默认账号和初始口令拿来测一遍二是内部安全巡检抽样检查员工口令里有没有公司名 123456这类规律三是数据恢复自己多年前加密的压缩包忘了密码用字典碰一碰大概率能想起来四是后端开发者验证自己选的哈希方案比如对比 bcrypt cost10 和 cost12 在同样字典下的耗时差异。不该碰的场景同样明确任何未授权的第三方系统、任何来源不明的哈希库、任何带有真实用户隐私的口令文件。还有一种情况容易被忽略——即便是自己的系统如果数据涉及他人信息跑之前也要走内部流程留存审计记录。工具用得规范才谈得上专业。2. John 的破解模式与核心原理拆解2.1 三种主力模式字典、单字规则、掩码暴力John 的核心是几种互补的候选密码生成策略理解它们各自的脾气才能用对。**字典模式Wordlist**是最直白的一种。你给它一个密码列表它逐个拿去做哈希比对。字典的质量直接决定成败。圈内常见的 rockyou.txt 收录了一千四百多万条真实泄露口令覆盖面很广但它有个缺点——对中文拼音、行业术语、企业专属词汇基本没辙。我的习惯是准备好几套字典通用大字典打底行业术语字典补充再用目标相关的关键词组织名、产品名、常见缩写现场拼一份小字典。定向字典命中率往往比大字典还高。**单字规则模式Single crack**很有意思它直接拿用户名、GECOS 字段也就是系统里记录的用户全名、联系方式等信息作为原材料套用大量变形规则去猜。比如用户名是zhangsan它会尝试Zhangsan、zhangsan123、zhangsan2024、zs、nasan这类变形。实测下来企业内部系统里用户名 简单后缀的命中率高得吓人这也是我建议所有系统都禁止口令包含用户名的原因。**掩码/增量模式Mask / Incremental**属于暴力穷举的智能版本。掩码模式允许你用占位符描述密码的形状比如?u?l?l?l?l?d?d?d?d表示一个大写 四个小写 四个数字John 只在这个形状空间里穷举效率比盲目全字符集高得多。增量模式则是 John 内置的马尔可夫链和字符频率模型它会根据训练数据判断哪些字符组合更可能出现把算力优先投给高概率候选。当你知道目标口令大概的长度和构成习惯时掩码是最省时间的刀。三种模式不是二选一实战里是接力跑先用单字规则秒掉一批弱口令再用字典扫一遍常见词最后对剩下的硬骨头用掩码定点爆破。2.2 哈希格式识别跑之前先认脸John 支持的格式有几百种每种在命令行里都有一个--format的名字比如ntWindows NTLM、sha512cryptLinux 现代系统、raw-md5、bcrypt、zip、rar、office等等。如果格式猜错你会看到类似no password hashes loaded没加载到哈希的报错或者跑半天一个都出不来。John 本身有自动识别能力启动时会尝试嗅探哈希的形态。但自动识别不是万能的尤其对付自定义格式或混合结构时。我的做法是拿到哈希先肉眼判断一眼看长度、看前缀、看分隔符结构。$6$ 开头基本是 sha512crypt$2a$ / $2b$ / $2y$ 开头是 bcrypt$1$ 是老的 md5crypt32 位纯十六进制可能是 raw-md5$NT$ 前缀或裸的 32 位十六进制也可能是 NTLM。拿不准就用john --listformats列出所有支持的格式再用john --formatxxx --test对格式做个自检。2.3 哈希与加盐为什么同密码不同值是好事再展开说一点原理因为它直接关系到你该怎么防御。无盐的哈希比如早期 Unix 的 crypt、裸 MD5有个致命弱点相同密码永远得到相同哈希。这意味着攻击者一旦撞出一个就等于撞出了所有用同一密码的账户还能直接查彩虹表。加盐之后每个账户的盐值不同同样的密码哈希值也完全不同撞库收益被彻底打散。更进一步的是慢哈希。sha512crypt 默认迭代 5000 轮bcrypt 通过 cost 参数控制每加 1 成本翻倍argon2 还能调节内存占用。这类函数让攻击者的单次尝试成本从微秒级抬到毫秒级。John 跑 bcryptcost12时普通 CPU 每秒可能只有几十次尝试这速度去碰一个 8 位复杂口令基本是天文数字的时间。所以防破解的第一条铁律从来不是把密码设长一点这么简单而是用慢哈希 每账户独立盐值 足够高的成本参数。3. 从环境准备到跑出第一个结果的完整实操3.1 安装优先用发行版包还是自己编译在 Debian/Ubuntu 系上sudo apt install john能装上的是一个相对精简的版本覆盖常见格式没问题但 jumbo 分支里的很多高级特性和扩展格式它没有。Kali 等安全发行版自带的就是功能较全的版本。想要完整能力建议从 Openwall 官网拉 jumbo 源码编译核心三步./configure make -s clean make -sj4。编译需要 gcc、make、libssl-dev、zlib 等依赖缺哪个装哪个。编译完成后可执行文件在run/目录下像 zip2john、rar2john、ssh2john、office2john 这类辅助脚本也都在那儿。我个人的习惯是把它固定装到一个目录然后把这个 run 目录加进 PATH随时调用。提示不同发行版打包的 John 版本差异较大命令行参数和格式名可能对不上。遇到这个参数明明文档里有却报错的情况先john --version看一眼版本别急着怀疑自己。3.2 自己造一个测试目标从零跑通第一轮正规的练习方式是自己造哈希。Linux 上想模拟一套用户口令文件可以这样操作先创建一个测试用户设置一个你已知的密码然后把/etc/shadow和/etc/passwd里对应行导出来用自带的unshadow工具合并成 John 能吃的格式sudo unshadow /etc/passwd /etc/shadow myhash.txt如果你不想动系统账户也可以用一个小脚本直接用 openssl 或 python 生成一个带盐的 sha512crypt 哈希丢进文件里练手。造好目标后字典模式的基本命令是john --wordlist/usr/share/wordlists/rockyou.txt --formatsha512crypt myhash.txt跑完想看结果和解出数量用john --show myhash.txt。这个--show很重要它把已解出和未解出分开列出方便你评估字典覆盖率。3.3 规则引擎让字典的命中率翻几倍光用原版字典很多密码猜不到加上规则引擎命中率会有质的提升。John 内置了--rules参数会自动套用它的默认规则集把字典里的每个词做大小写变化、加数字后缀、替换字符a→、o→0、e→3等几十种变形。命令大致是john --wordlistwords.txt --rules --formatnt myhash.txtjumbo 版还支持--rulesJumbo、--rulesKoreLogic等不同规则集甚至可以用--rules-stack把多套规则叠加。这里有个经验规则不是越多越好。规则集越大单位时间处理的候选越少。粗跑阶段用默认规则快速扫一遍定向阶段再上重规则节奏把握好。3.4 掩码模式已知密码形状时的精准打击假设你从某个系统的口令策略推断出密码是首字母大写 五个小写 两位数字那掩码模式就是最优解john --mask?u?l?l?l?l?l?d?d --formatsha512crypt myhash.txtJohn 的掩码占位符里?l小写、?u大写、?d数字、?s符号、?a全字符集。它还有个高级用法叫混合掩码可以只对密码的某个位置做穷举其余位置用已知片段固定比如你知道密码开头是公司缩写就可以把那段写死只爆后面几位。这种知道一半的场景掩码的效率是字典的好几倍。3.5 压缩包与办公文档zip2john 系列的用法热搜里提到的 zip 密码破解就是 John 这套辅助脚本的典型应用。加密 ZIP、RAR、7z、PDF、Office 文档John 都不能直接吃得先用对应的转换脚本把加密结构提取成哈希格式。以 ZIP 为例zip2john secret.zip zip.hash john --wordlistwords.txt zip.hashzip2john会把 ZIP 里的加密信息抽出来生成 John 能识别的哈希串。这里提醒一句传统 ZipCrypto 加密的压缩包用字典碰出来的速度很快但如果是 AES-256 加密的 ZIPJohn 跑起来会慢很多因为每次验证都要做一遍密钥派生。这也是一个很好的防御启示——你给别人发加密压缩包时挑 AES 加密的安全性远高于老式 ZipCrypto。4. 提速与资源调度把跑批的效率榨出来4.1 硬件选择与算力估算决定 John 速度的第一因素是硬件第二是哈希算法本身。粗略地说针对无盐的快速哈希如 raw-md5、NTLM一块中端 GPU 每秒能跑几十亿次换成 bcrypt 这类慢哈希同样的卡每秒只剩几千次差了六个数量级。所以在动手前值得先花五分钟做一道算术题目标哈希属于哪一类、你手头的机器每秒能试多少次、候选空间有多大、你能接受跑多久。很多人一上来就挂机开跑结果发现按当前速度要跑几十年白白浪费电。算力估算的实用办法是用--test或先跑一分钟看速率输出。John 运行时会实时显示类似1234p/s的速率p 是 per second每秒尝试数拿它乘上你字典的条目数就知道这一轮大概要多久。心里有数之后再决定要不要换策略比闷头等强。4.2 关键命令行参数与调优思路几个我常用的参数值得说清楚。--forkN可以多进程并行把多核 CPU 吃满在字典模式下收益明显。--nodeM/N是把候选空间切成 N 份、当前机器处理第 M 份适合多台机器分工。--min-length和--max-length限制候选长度避免在明显不可能的长度区间浪费算力。--sessionname给本次任务起个名字配合--restore就能断点续跑——这个功能对长时间任务太重要了机器重启或者你手滑 CtrlC 之后用john --restorename能接着上次的进度跑不会从头再来。提示跑大任务之前务必用--session命名。我吃过不止一次亏跑了半天的任务因为没存会话一个中断全部重来。4.3 断点续跑与结果管理John 有个很好用的机制它默认会把进度存在~/.john/john.pot里这个文件记录所有已解出的哈希:明文对。下次对同一批哈希运行时它会自动跳过已经解出的只处理剩下的。所以如果你分几轮跑不同字典、不同模式不用担心重复劳动John 自己会去重。管理多个任务时建议按项目建目录哈希文件、字典、会话文件分开放并在文件名里带上日期和模式比如20240315_nt_rules.session。隔一段时间回头看你能清楚知道每一轮用了什么策略、解出多少便于复盘和优化下一轮。这种工程化的习惯是业余和专业的差距所在。5. 防破解把密码强度真正做上去讲完攻击面回到这篇文章另一半更有价值的内容——防御。既然我们知道了 John 是怎么工作的反过来就知道该堵哪些口子。5.1 从哈希算法层面把地基打牢如果系统是你自己开发或选型的密码存储方案是第一道防线。能用 argon2id 就用它它在抗 GPU 和抗专用硬件方面是目前公认较强的选择退一步用 bcryptcost 参数别低于 10能上 12 更好要在登录延迟可接受的前提下再退一步用 PBKDF2迭代次数往高了配几十万轮是常见起点。绝对不要用裸 MD5、裸 SHA1、裸 SHA256 存密码这些算法快得离谱等于给攻击者开了绿灯。还有个容易被忽略的点salt 必须每个账户独立、足够随机、长度充足16 字节以上。见过有系统为了省事用全局固定 salt那加盐的意义基本没了。另外加密密钥和哈希存储要分离别把密钥和密文放在同一个库里不然被拖库时一锅端。5.2 口令策略与用户习惯的博弈强制复杂性大小写 数字 符号 最小长度是常规操作但光靠它容易催生Password1!这种可预测的模式。更有效的组合拳是设置合理的最小长度12 位起、用黑名单挡掉常见弱口令和已泄露口令、禁止口令包含用户名和公司名、定期检查是否有口令出现在泄露库中。NIST 最新的建议其实倾向于重长度轻复杂度、不强制定期更换因为频繁换密码反而让用户搞出Spring2024!→Summer2024!这种规律变形。具体怎么权衡要看你所在环境的风险模型。用户教育这块也很关键。很多口令之所以被秒破不是技术问题是习惯问题——生日、手机号、宠物名、键盘路径qwerty、1qaz2wsx占了泄露库的一大块。John 的字典里这些词都在跑起来就是几秒钟的事。5.3 系统侧的限速、锁定与多因素假设密码存储已经做扎实了还有一层防护要补限制在线猜测。数据库拖库是离线攻击password hash 落到攻击者手里你再怎么限速也没用但如果攻击者只能在线猜那限速、失败锁定、验证码、异常登录检测就是有效手段。比如同一 IP 连续失败 5 次锁定 15 分钟、指数退避、异地登录二次验证。多因素认证MFA是终极的兜底。即便口令被猜中攻击者还缺第二因素动态口令、硬件密钥、生物特征。对管理员账户、远程访问入口这类高价值目标MFA 应该是默认开启而不是可选项。我见过的真实案例里口令泄露但因为有 MFA 而没造成实质损失的场景比没有 MFA 而翻车的多得多。5.4 把 John 用在防御方自查清单防御方怎么用 John推荐一套自查流程定期导出自有系统的哈希在合规前提下用通用字典 规则跑一轮把所有解出的口令列出来看看有没有共性问题比如某个部门普遍用同一套命名规则把结果脱敏后向上汇报推动口令策略调整改完策略过一段时间再跑一轮对比命中率有没有下降。这个检测—整改—复测的闭环才是安全建设的正确姿势。注意自查过程中拿到的明文口令属于高危敏感数据用完必须立即销毁任何人都不该留存。这是职业操守也是合规底线。6. 常见问题与排查技巧实录跑 John 的过程中新手最容易卡在几个固定的地方。我整理成表方便你对照排查。现象大概率原因排查与解决提示 no password hashes loaded格式没认出来或文件路径/内容有误用--format手动指定用--listformats查支持格式检查哈希文件是不是被编辑器搞乱了换行跑了很久一个都没出字典不匹配、算法太慢、候选空间太大先换小字典快速验证流程确认格式正确用--test看速率估算总时长解出的结果看不到忘了用--show跑完执行john --show 哈希文件或直接查~/.john/john.pot中途中断要重跑没设置 session加--session名字中断后用--restore名字续跑压缩包提取哈希报错脚本版本旧或压缩格式特殊更新到 jumbo 版 John确认 zip2john 等脚本在 PATH 里Windows 哈希认不出NTLM 和 LM 混淆明确指定--formatnt或--formatlm二者结构不同除了表里的还有几个踩坑经验值得单独说。一是字符编码问题字典文件如果编码不一致含中文或特殊字符的候选可能被 John 读错建议统一用 UTF-8必要时先用工具去重和清洗。二是字典膨胀的陷阱有人喜欢把几十份字典无脑合并成一个超大字典结果跑得慢还不见得命中率高因为重复条目多、噪声大。正确的做法是先去重、再按命中率和你的目标相关性排序。三是过度迷信暴力穷举很多人觉得算力够就能破一切实际上一个 12 位随机复杂口令的穷举空间大到现代硬件也望尘莫及真正的攻击者靠的从来是字典和规则而不是硬刚。所以防御方的重点恰恰是让用户的口令跳出字典和规则的覆盖范围。7. 一些个人体会我从几年前开始把 John 当作日常安全自查的固定环节最大的感受是密码安全这件事技术手段只能解决一半另一半靠的是流程和习惯。工具再强如果组织里没有定期审计的机制没有对弱口令的整改闭环那每次检查都是走个过场问题永远存在。反过来只要每季度老老实实跑一轮、认真整改、下季度复测口令的整体强度是肉眼可见在提升的。另一个体会是别把 John 神化也别把它妖魔化。它就是一把尺子量的是你的密码到底有多结实。真想提升安全性与其纠结攻击者手里有什么工具不如把存储算法升级到慢哈希、把 salt 做足随机、把 MFA 铺开、把弱口令黑名单维护起来——这些防御动作的投入产出比远高于事后发现被破了再补救。至于那个忘了密码的加密压缩包用字典碰一碰很多时候确实能想起来当初自己是怎么设的这算是 John 最无害也最实用的一面了。
John the Ripper密码审计：从哈希加盐到防破解实战
John the Ripper圈子里一般直接叫它 John是密码审计这件事上绕不开的一个老牌工具。它最早在 1996 年由 Openwall 项目的 Solar Designer 发布最初只针对 Unix 系统的口令文件后来演化出社区维护的 jumbo 分支支持的哈希格式一口气堆到了几百种从 Linux 的 sha512crypt、Windows 的 NTLM到各种数据库、压缩包、办公文档的加密结构基本都能吃。很多人一听到密码破解四个字就下意识往灰色地带联想其实 John 的主战场是防御方系统管理员用它给自己服务器上的口令做一次强度体检运维用它审计外包系统残留的弱口令开发者用它验证自己的加盐和迭代参数够不够硬。它解决的核心问题就一句话——你自以为很安全的密码到底扛不扛得住字典和规则的轮番冲击。这篇文章适合安全入门的新手、负责系统加固的运维以及想搞清楚密码存储原理的后端开发者。全程只以本地自建测试环境和自有数据为对象讲清楚原理、实操和防御思路不涉及任何越界场景。1. 为什么密码审计绕不开 John1.1 密码存储的真相所谓破解其实是在猜哈希先把一个容易误解的点说透。服务器上从来不保存你的明文密码它保存的是密码经过某种单向函数运算后的结果也就是哈希值。这个函数的特点是正向计算很快反向推算极难——给定一个密码算哈希眨眼的功夫给定一个哈希想还原密码理论上只能靠穷举。所以 John 干的事情本质上是猜测 验证的循环它不断生成候选密码对每个候选做同样的哈希运算再和你提供的目标哈希比对一旦对上了就说明猜中了。这个过程完全没有攻破算法的玄学成分纯粹是算力和候选质量的比拼。理解了这一点很多现象就顺理成章了。为什么同一个密码在不同机器上哈希值长得完全不一样因为绝大多数现代系统会加盐值salt——一段随机数据和密码拼在一起再算哈希。盐值让彩虹表这种预先算好海量哈希的作弊手段失效因为攻击者得针对每一个盐值重新算一遍成本瞬间抬高几个数量级。John 处理带盐哈希时会先解析出盐值再对每个候选密码套用对应的盐重新计算。这也是为什么 John 的第一步永远是识别格式格式认错了盐值解析错了后面所有计算都是白费。还有一个概念是迭代次数cost / rounds。像 bcrypt、sha512crypt、PBKDF2 这类专为密码设计的函数会故意把一次哈希运算重复几千上万次目的就是拖慢单次验证。对你登录来说多花几十毫秒无感对攻击者来说算力被硬生生稀释成千分之一。John 跑这类哈希时速度会肉眼可见地掉下来这不是它不行而是算法设计就是这么要求的。所以我常说判断一个系统密码存储做得好不好看它用的什么哈希、迭代多少轮比看它有没有加密这种模糊说法靠谱得多。1.2 John 的定位它不是黑客工具而是密码强度体检仪在安全圈里工具本身没有善恶用法才决定性质。John 被大量渗透测试团队带进授权项目干的就是我能不能在两小时内把甲方这批口令猜出来这一件事。猜得出来说明口令策略不及格该改猜不出来说明现有策略扛得住常见攻击面。这跟医生拿听诊器听心跳是一个逻辑——工具是诊断用的。它和另一个常被拿来比较的工具 Hashcat 有什么差别简单说Hashcat 更偏重 GPU 上的极限吞吐追求每秒几十亿次的算力适合大规模哈希库的批量爆破John 的优势在于格式覆盖面广、自带规则引擎和多种智能模式、开箱即用尤其适合针对少量目标做精细化的定向分析。做口令审计时我通常是先用 John 快速跑一轮字典和单字规则看看有没有low-hanging fruit低垂的果实比如用户名变形、常见年份后缀这类;真要上大规模算力才切到 Hashcat。两者不是替代关系是分工。需要把红线划清楚John 只能用在你拥有或获得明确书面授权的系统上。对别人的系统跑哈希猜测不管出于什么动机都是违法的。本文后面所有的演示都以自己生成的测试哈希为准你在自己电脑上照做跑出来的结果也只属于你自己。1.3 什么场景下该用、什么场景下碰都别碰适合用 John 的场景我列几个典型的一是新系统上线前把默认账号和初始口令拿来测一遍二是内部安全巡检抽样检查员工口令里有没有公司名 123456这类规律三是数据恢复自己多年前加密的压缩包忘了密码用字典碰一碰大概率能想起来四是后端开发者验证自己选的哈希方案比如对比 bcrypt cost10 和 cost12 在同样字典下的耗时差异。不该碰的场景同样明确任何未授权的第三方系统、任何来源不明的哈希库、任何带有真实用户隐私的口令文件。还有一种情况容易被忽略——即便是自己的系统如果数据涉及他人信息跑之前也要走内部流程留存审计记录。工具用得规范才谈得上专业。2. John 的破解模式与核心原理拆解2.1 三种主力模式字典、单字规则、掩码暴力John 的核心是几种互补的候选密码生成策略理解它们各自的脾气才能用对。**字典模式Wordlist**是最直白的一种。你给它一个密码列表它逐个拿去做哈希比对。字典的质量直接决定成败。圈内常见的 rockyou.txt 收录了一千四百多万条真实泄露口令覆盖面很广但它有个缺点——对中文拼音、行业术语、企业专属词汇基本没辙。我的习惯是准备好几套字典通用大字典打底行业术语字典补充再用目标相关的关键词组织名、产品名、常见缩写现场拼一份小字典。定向字典命中率往往比大字典还高。**单字规则模式Single crack**很有意思它直接拿用户名、GECOS 字段也就是系统里记录的用户全名、联系方式等信息作为原材料套用大量变形规则去猜。比如用户名是zhangsan它会尝试Zhangsan、zhangsan123、zhangsan2024、zs、nasan这类变形。实测下来企业内部系统里用户名 简单后缀的命中率高得吓人这也是我建议所有系统都禁止口令包含用户名的原因。**掩码/增量模式Mask / Incremental**属于暴力穷举的智能版本。掩码模式允许你用占位符描述密码的形状比如?u?l?l?l?l?d?d?d?d表示一个大写 四个小写 四个数字John 只在这个形状空间里穷举效率比盲目全字符集高得多。增量模式则是 John 内置的马尔可夫链和字符频率模型它会根据训练数据判断哪些字符组合更可能出现把算力优先投给高概率候选。当你知道目标口令大概的长度和构成习惯时掩码是最省时间的刀。三种模式不是二选一实战里是接力跑先用单字规则秒掉一批弱口令再用字典扫一遍常见词最后对剩下的硬骨头用掩码定点爆破。2.2 哈希格式识别跑之前先认脸John 支持的格式有几百种每种在命令行里都有一个--format的名字比如ntWindows NTLM、sha512cryptLinux 现代系统、raw-md5、bcrypt、zip、rar、office等等。如果格式猜错你会看到类似no password hashes loaded没加载到哈希的报错或者跑半天一个都出不来。John 本身有自动识别能力启动时会尝试嗅探哈希的形态。但自动识别不是万能的尤其对付自定义格式或混合结构时。我的做法是拿到哈希先肉眼判断一眼看长度、看前缀、看分隔符结构。$6$ 开头基本是 sha512crypt$2a$ / $2b$ / $2y$ 开头是 bcrypt$1$ 是老的 md5crypt32 位纯十六进制可能是 raw-md5$NT$ 前缀或裸的 32 位十六进制也可能是 NTLM。拿不准就用john --listformats列出所有支持的格式再用john --formatxxx --test对格式做个自检。2.3 哈希与加盐为什么同密码不同值是好事再展开说一点原理因为它直接关系到你该怎么防御。无盐的哈希比如早期 Unix 的 crypt、裸 MD5有个致命弱点相同密码永远得到相同哈希。这意味着攻击者一旦撞出一个就等于撞出了所有用同一密码的账户还能直接查彩虹表。加盐之后每个账户的盐值不同同样的密码哈希值也完全不同撞库收益被彻底打散。更进一步的是慢哈希。sha512crypt 默认迭代 5000 轮bcrypt 通过 cost 参数控制每加 1 成本翻倍argon2 还能调节内存占用。这类函数让攻击者的单次尝试成本从微秒级抬到毫秒级。John 跑 bcryptcost12时普通 CPU 每秒可能只有几十次尝试这速度去碰一个 8 位复杂口令基本是天文数字的时间。所以防破解的第一条铁律从来不是把密码设长一点这么简单而是用慢哈希 每账户独立盐值 足够高的成本参数。3. 从环境准备到跑出第一个结果的完整实操3.1 安装优先用发行版包还是自己编译在 Debian/Ubuntu 系上sudo apt install john能装上的是一个相对精简的版本覆盖常见格式没问题但 jumbo 分支里的很多高级特性和扩展格式它没有。Kali 等安全发行版自带的就是功能较全的版本。想要完整能力建议从 Openwall 官网拉 jumbo 源码编译核心三步./configure make -s clean make -sj4。编译需要 gcc、make、libssl-dev、zlib 等依赖缺哪个装哪个。编译完成后可执行文件在run/目录下像 zip2john、rar2john、ssh2john、office2john 这类辅助脚本也都在那儿。我个人的习惯是把它固定装到一个目录然后把这个 run 目录加进 PATH随时调用。提示不同发行版打包的 John 版本差异较大命令行参数和格式名可能对不上。遇到这个参数明明文档里有却报错的情况先john --version看一眼版本别急着怀疑自己。3.2 自己造一个测试目标从零跑通第一轮正规的练习方式是自己造哈希。Linux 上想模拟一套用户口令文件可以这样操作先创建一个测试用户设置一个你已知的密码然后把/etc/shadow和/etc/passwd里对应行导出来用自带的unshadow工具合并成 John 能吃的格式sudo unshadow /etc/passwd /etc/shadow myhash.txt如果你不想动系统账户也可以用一个小脚本直接用 openssl 或 python 生成一个带盐的 sha512crypt 哈希丢进文件里练手。造好目标后字典模式的基本命令是john --wordlist/usr/share/wordlists/rockyou.txt --formatsha512crypt myhash.txt跑完想看结果和解出数量用john --show myhash.txt。这个--show很重要它把已解出和未解出分开列出方便你评估字典覆盖率。3.3 规则引擎让字典的命中率翻几倍光用原版字典很多密码猜不到加上规则引擎命中率会有质的提升。John 内置了--rules参数会自动套用它的默认规则集把字典里的每个词做大小写变化、加数字后缀、替换字符a→、o→0、e→3等几十种变形。命令大致是john --wordlistwords.txt --rules --formatnt myhash.txtjumbo 版还支持--rulesJumbo、--rulesKoreLogic等不同规则集甚至可以用--rules-stack把多套规则叠加。这里有个经验规则不是越多越好。规则集越大单位时间处理的候选越少。粗跑阶段用默认规则快速扫一遍定向阶段再上重规则节奏把握好。3.4 掩码模式已知密码形状时的精准打击假设你从某个系统的口令策略推断出密码是首字母大写 五个小写 两位数字那掩码模式就是最优解john --mask?u?l?l?l?l?l?d?d --formatsha512crypt myhash.txtJohn 的掩码占位符里?l小写、?u大写、?d数字、?s符号、?a全字符集。它还有个高级用法叫混合掩码可以只对密码的某个位置做穷举其余位置用已知片段固定比如你知道密码开头是公司缩写就可以把那段写死只爆后面几位。这种知道一半的场景掩码的效率是字典的好几倍。3.5 压缩包与办公文档zip2john 系列的用法热搜里提到的 zip 密码破解就是 John 这套辅助脚本的典型应用。加密 ZIP、RAR、7z、PDF、Office 文档John 都不能直接吃得先用对应的转换脚本把加密结构提取成哈希格式。以 ZIP 为例zip2john secret.zip zip.hash john --wordlistwords.txt zip.hashzip2john会把 ZIP 里的加密信息抽出来生成 John 能识别的哈希串。这里提醒一句传统 ZipCrypto 加密的压缩包用字典碰出来的速度很快但如果是 AES-256 加密的 ZIPJohn 跑起来会慢很多因为每次验证都要做一遍密钥派生。这也是一个很好的防御启示——你给别人发加密压缩包时挑 AES 加密的安全性远高于老式 ZipCrypto。4. 提速与资源调度把跑批的效率榨出来4.1 硬件选择与算力估算决定 John 速度的第一因素是硬件第二是哈希算法本身。粗略地说针对无盐的快速哈希如 raw-md5、NTLM一块中端 GPU 每秒能跑几十亿次换成 bcrypt 这类慢哈希同样的卡每秒只剩几千次差了六个数量级。所以在动手前值得先花五分钟做一道算术题目标哈希属于哪一类、你手头的机器每秒能试多少次、候选空间有多大、你能接受跑多久。很多人一上来就挂机开跑结果发现按当前速度要跑几十年白白浪费电。算力估算的实用办法是用--test或先跑一分钟看速率输出。John 运行时会实时显示类似1234p/s的速率p 是 per second每秒尝试数拿它乘上你字典的条目数就知道这一轮大概要多久。心里有数之后再决定要不要换策略比闷头等强。4.2 关键命令行参数与调优思路几个我常用的参数值得说清楚。--forkN可以多进程并行把多核 CPU 吃满在字典模式下收益明显。--nodeM/N是把候选空间切成 N 份、当前机器处理第 M 份适合多台机器分工。--min-length和--max-length限制候选长度避免在明显不可能的长度区间浪费算力。--sessionname给本次任务起个名字配合--restore就能断点续跑——这个功能对长时间任务太重要了机器重启或者你手滑 CtrlC 之后用john --restorename能接着上次的进度跑不会从头再来。提示跑大任务之前务必用--session命名。我吃过不止一次亏跑了半天的任务因为没存会话一个中断全部重来。4.3 断点续跑与结果管理John 有个很好用的机制它默认会把进度存在~/.john/john.pot里这个文件记录所有已解出的哈希:明文对。下次对同一批哈希运行时它会自动跳过已经解出的只处理剩下的。所以如果你分几轮跑不同字典、不同模式不用担心重复劳动John 自己会去重。管理多个任务时建议按项目建目录哈希文件、字典、会话文件分开放并在文件名里带上日期和模式比如20240315_nt_rules.session。隔一段时间回头看你能清楚知道每一轮用了什么策略、解出多少便于复盘和优化下一轮。这种工程化的习惯是业余和专业的差距所在。5. 防破解把密码强度真正做上去讲完攻击面回到这篇文章另一半更有价值的内容——防御。既然我们知道了 John 是怎么工作的反过来就知道该堵哪些口子。5.1 从哈希算法层面把地基打牢如果系统是你自己开发或选型的密码存储方案是第一道防线。能用 argon2id 就用它它在抗 GPU 和抗专用硬件方面是目前公认较强的选择退一步用 bcryptcost 参数别低于 10能上 12 更好要在登录延迟可接受的前提下再退一步用 PBKDF2迭代次数往高了配几十万轮是常见起点。绝对不要用裸 MD5、裸 SHA1、裸 SHA256 存密码这些算法快得离谱等于给攻击者开了绿灯。还有个容易被忽略的点salt 必须每个账户独立、足够随机、长度充足16 字节以上。见过有系统为了省事用全局固定 salt那加盐的意义基本没了。另外加密密钥和哈希存储要分离别把密钥和密文放在同一个库里不然被拖库时一锅端。5.2 口令策略与用户习惯的博弈强制复杂性大小写 数字 符号 最小长度是常规操作但光靠它容易催生Password1!这种可预测的模式。更有效的组合拳是设置合理的最小长度12 位起、用黑名单挡掉常见弱口令和已泄露口令、禁止口令包含用户名和公司名、定期检查是否有口令出现在泄露库中。NIST 最新的建议其实倾向于重长度轻复杂度、不强制定期更换因为频繁换密码反而让用户搞出Spring2024!→Summer2024!这种规律变形。具体怎么权衡要看你所在环境的风险模型。用户教育这块也很关键。很多口令之所以被秒破不是技术问题是习惯问题——生日、手机号、宠物名、键盘路径qwerty、1qaz2wsx占了泄露库的一大块。John 的字典里这些词都在跑起来就是几秒钟的事。5.3 系统侧的限速、锁定与多因素假设密码存储已经做扎实了还有一层防护要补限制在线猜测。数据库拖库是离线攻击password hash 落到攻击者手里你再怎么限速也没用但如果攻击者只能在线猜那限速、失败锁定、验证码、异常登录检测就是有效手段。比如同一 IP 连续失败 5 次锁定 15 分钟、指数退避、异地登录二次验证。多因素认证MFA是终极的兜底。即便口令被猜中攻击者还缺第二因素动态口令、硬件密钥、生物特征。对管理员账户、远程访问入口这类高价值目标MFA 应该是默认开启而不是可选项。我见过的真实案例里口令泄露但因为有 MFA 而没造成实质损失的场景比没有 MFA 而翻车的多得多。5.4 把 John 用在防御方自查清单防御方怎么用 John推荐一套自查流程定期导出自有系统的哈希在合规前提下用通用字典 规则跑一轮把所有解出的口令列出来看看有没有共性问题比如某个部门普遍用同一套命名规则把结果脱敏后向上汇报推动口令策略调整改完策略过一段时间再跑一轮对比命中率有没有下降。这个检测—整改—复测的闭环才是安全建设的正确姿势。注意自查过程中拿到的明文口令属于高危敏感数据用完必须立即销毁任何人都不该留存。这是职业操守也是合规底线。6. 常见问题与排查技巧实录跑 John 的过程中新手最容易卡在几个固定的地方。我整理成表方便你对照排查。现象大概率原因排查与解决提示 no password hashes loaded格式没认出来或文件路径/内容有误用--format手动指定用--listformats查支持格式检查哈希文件是不是被编辑器搞乱了换行跑了很久一个都没出字典不匹配、算法太慢、候选空间太大先换小字典快速验证流程确认格式正确用--test看速率估算总时长解出的结果看不到忘了用--show跑完执行john --show 哈希文件或直接查~/.john/john.pot中途中断要重跑没设置 session加--session名字中断后用--restore名字续跑压缩包提取哈希报错脚本版本旧或压缩格式特殊更新到 jumbo 版 John确认 zip2john 等脚本在 PATH 里Windows 哈希认不出NTLM 和 LM 混淆明确指定--formatnt或--formatlm二者结构不同除了表里的还有几个踩坑经验值得单独说。一是字符编码问题字典文件如果编码不一致含中文或特殊字符的候选可能被 John 读错建议统一用 UTF-8必要时先用工具去重和清洗。二是字典膨胀的陷阱有人喜欢把几十份字典无脑合并成一个超大字典结果跑得慢还不见得命中率高因为重复条目多、噪声大。正确的做法是先去重、再按命中率和你的目标相关性排序。三是过度迷信暴力穷举很多人觉得算力够就能破一切实际上一个 12 位随机复杂口令的穷举空间大到现代硬件也望尘莫及真正的攻击者靠的从来是字典和规则而不是硬刚。所以防御方的重点恰恰是让用户的口令跳出字典和规则的覆盖范围。7. 一些个人体会我从几年前开始把 John 当作日常安全自查的固定环节最大的感受是密码安全这件事技术手段只能解决一半另一半靠的是流程和习惯。工具再强如果组织里没有定期审计的机制没有对弱口令的整改闭环那每次检查都是走个过场问题永远存在。反过来只要每季度老老实实跑一轮、认真整改、下季度复测口令的整体强度是肉眼可见在提升的。另一个体会是别把 John 神化也别把它妖魔化。它就是一把尺子量的是你的密码到底有多结实。真想提升安全性与其纠结攻击者手里有什么工具不如把存储算法升级到慢哈希、把 salt 做足随机、把 MFA 铺开、把弱口令黑名单维护起来——这些防御动作的投入产出比远高于事后发现被破了再补救。至于那个忘了密码的加密压缩包用字典碰一碰很多时候确实能想起来当初自己是怎么设的这算是 John 最无害也最实用的一面了。
错误本质：信任链断裂而非网络故障)
