Web安全实战：从字典到机器学习，构建完整口令破解攻击链

简介这份资源面向国科大Web安全技术课程的学习者聚焦口令破解大作业中的代码实现部分适合已掌握Python基础、希望理解口令安全分析流程的高年级本科生或研究生参考。内容围绕密码特征提取、密码特征统计与密码暴力猜测三条主线展开可配合课程实验复现完整分析链路。压缩包共155个文件约170.54MB以txt数据与说明、csv统计结果、py脚本为主辅以sample样本、png图表及xlsx表格另有少量Git版本控制与工程配置文件便于按模块查阅与二次修改。目前已有373人学习下载。读者可从中获得口令特征构造与统计的具体实现思路、暴力猜测脚本的编写框架以及基于真实数据集如csdn、yahoo的预处理与训练样例适合作为课程作业参考与安全实验的起步材料。1. 口令破解作业到底在练什么从一份字典到一次完整攻击链很多人第一次听到“口令破解大作业”脑子里浮现的是电影里那种黑底绿字、几秒钟滚出密码的画面。真把一份 Web 安全课程的口令破解作业摊开来看你会发现它练的根本不是“猜密码”这个动作而是一条完整的攻击链先拿到目标系统的口令存储形态再判断它用的是明文、哈希还是加盐哈希然后选字典、选规则、选算力最后把结果整理成一份能说清“为什么这个口令会被破”的报告。这份资源就是围绕这条链路组织的关键词里出现的 Web 安全技术、口令破解、机器学习分别对应链路上的三个环节——Web 侧的口令获取面、离线破解的工程实现、以及用模型去预测口令强度或生成候选口令。它适合两类人一类是刚学完 Web 安全基础、想找一个能真正跑起来的综合练习的在校开发者另一类是已经会写脚本、但没系统做过口令强度评估的安全方向同学。下面我按“这东西由什么组成、怎么跑起来、哪里会翻车、怎么改成自己的”这个顺序拆。2. 项目结构与技术选型一个离线破解实验台是怎么搭起来的2.1 目录骨架与各模块职责这类作业型项目通常不会是一个巨型工程而是一个“脚本 数据 报告”的组合体。我拿到手的目录大致长这样不同人做会有出入但分层逻辑基本一致password-crack-lab/ ├── data/ │ ├── rockyou_sample.txt # 字典样本按行存放候选口令 │ ├── rules/ │ │ └── best64.rule # hashcat 规则文件做变形扩展 │ └── targets/ │ └── hashes.txt # 待破解的哈希列表一行一个 ├── src/ │ ├── hash_gen.py # 生成测试用哈希模拟“拿到库”的场景 │ ├── dict_attack.py # 纯 Python 字典攻击教学用 │ ├── rule_engine.py # 规则变形大小写、追加数字、替换字符 │ ├── ml_predict.py # 用分类模型预测口令强度 │ └── report.py # 汇总破解率、耗时、命中分布 ├── config.yaml # 字典路径、哈希类型、并发数等参数 └── README.md这个骨架的价值在于把“攻击”拆成了可单独验证的零件。hash_gen.py负责造靶子dict_attack.py负责最朴素的碰撞rule_engine.py负责把字典放大ml_predict.py负责回答“哪些口令即使没被破出来也很弱”report.py负责把数字变成结论。很多同学一上来就调外部工具结果报告里只有“破了多少个”说不清命中来自字典还是规则这个分层就是用来解决这个问题的。技术选型上纯 Python 负责教学和可读性真正的算力活交给成熟工具。常见做法是Python 写流程编排和结果分析哈希计算密集的部分用hashcat或john跑Python 只负责生成命令、解析输出。这样既不会在作业里陷入“手写 SHA-256 循环”的性能泥潭又能把每一步的参数讲清楚。2.2 哈希生成先把靶子造对离线破解的前提是“你手里有一份哈希”。作业里通常不允许碰真实系统所以要自己造。下面这段是hash_gen.py的核心负责把明文口令转成指定算法的哈希import hashlib def gen_hash(plain: str, algo: str md5, salt: str ) - str: 把明文口令转成哈希字符串。 algo: md5 / sha1 / sha256对应不同作业要求 salt: 加盐场景下拼在口令前面模拟真实库的存储方式 raw (salt plain).encode(utf-8) # 加盐时盐在前这是常见约定 if algo md5: return hashlib.md5(raw).hexdigest() if algo sha1: return hashlib.sha1(raw).hexdigest() if algo sha256: return hashlib.sha256(raw).hexdigest() raise ValueError(funsupported algo: {algo}) if __name__ __main__: # 造 5 条测试数据明文故意选弱口令方便后面验证命中 samples [123456, password, qwerty, admin888, Pssw0rd] for p in samples: print(f{p}\t{gen_hash(p, md5)})这段代码的关键不在哈希函数本身而在salt参数的位置。真实系统里盐可能拼在前、拼在后、甚至和口令做多次组合作业里如果只做无盐 MD5破解率会虚高报告结论就站不住。我一般会要求至少做一组“加盐 SHA-256”的对照用来说明“同样的字典加盐后命中率掉多少”。algo参数对应作业里常见的三种要求salt留空就是无盐场景。跑完把输出重定向到data/targets/hashes.txt靶子就有了。2.3 字典攻击与规则引擎把一份字典放大十倍纯字典攻击的逻辑很直白逐行读字典逐条算哈希和靶子比对。教学版用 Python 写清楚流程即可import hashlib def dict_attack(hashes: dict, dict_path: str, algo: str md5) - dict: hashes: {哈希值: 原始明文占位}返回 {哈希值: 命中的口令} dict_path: 字典文件路径一行一个候选 cracked {} with open(dict_path, r, encodingutf-8, errorsignore) as f: for line in f: cand line.strip() if not cand: continue h hashlib.md5(cand.encode()).hexdigest() if h in hashes and h not in cracked: cracked[h] cand # 命中即记录避免重复计算 return crackedhashes用字典而不是列表是为了把比对从 O(n) 降到 O(1)这是最容易被忽略却最影响体感的一处。errorsignore是因为真实字典里常混入非 UTF-8 字符不处理会直接抛异常中断。但真实口令很少是字典原词password1、Password、pssword都是变形。规则引擎就是干这个的def apply_rules(word: str) - list: 对单个词做常见变形返回候选列表。 覆盖首字母大写、全大写、追加 0-9、常见字符替换 out {word, word.capitalize(), word.upper()} for d in 0123456789: out.add(word d) trans str.maketrans({a: , o: 0, s: $, i: 1}) out.add(word.translate(trans)) return list(out)apply_rules返回的是集合转列表去重是必要的否则同一个候选会被算多次。字符替换表只放了四个最常见映射作业里可以按需扩展。把字典攻击和规则引擎串起来命中率通常能从个位数拉到两三成这个提升幅度本身就是报告里最有说服力的一段数据。2.4 机器学习模块预测强度而不是硬碰硬关键词里的“机器学习”在这个项目里通常不是用来加速破解而是用来做口令强度预测或候选生成。一个可落地的做法是把口令转成字符级特征训练一个二分类模型判断“弱/强”from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression def train_strength_model(passwords: list, labels: list): passwords: 口令字符串列表labels: 1 表示弱口令0 表示强口令 字符 n-gram 比词级特征更适合口令这种短文本 vec TfidfVectorizer(analyzerchar, ngram_range(1, 3)) X vec.fit_transform(passwords) clf LogisticRegression(max_iter1000).fit(X, labels) return vec, clfanalyzerchar和ngram_range(1, 3)是这段的核心口令没有“词”的概念按字符切 1 到 3 元组才能捕捉123、abc这类模式。max_iter1000是为了避免小样本下不收敛的警告。这个模型的作用是给报告加一个维度——不只说“破了多少”还能说“剩下没破的口令里模型判为弱的占多少”从而指出字典覆盖的盲区。3. 把实验跑起来从环境准备到第一份破解报告3.1 环境与依赖安装这类项目对环境的依赖不重Python 3.8 以上加几个库就够。我一般用虚拟环境隔离避免和系统里的包打架python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install scikit-learn pandas pyyamlscikit-learn给机器学习模块用pandas用来做结果统计和导出pyyaml读config.yaml。如果作业要求调用hashcat那是系统级工具不在 pip 里需要单独装装完用hashcat --version确认能调起来。这一步最常见的翻车是虚拟环境没激活就装包结果脚本跑起来报ModuleNotFoundError回头一看包装到系统 Python 里去了。3.2 配置文件与参数含义config.yaml是把“写死的脚本”变成“可复现实验”的关键。一个够用的配置长这样dict_path: data/rockyou_sample.txt hash_file: data/targets/hashes.txt algo: md5 use_rules: true rule_file: data/rules/best64.rule concurrency: 4 report_out: report/result.csvalgo要和hash_gen.py生成时一致不一致会导致零命中这是新手最容易怀疑“代码有 bug”其实只是参数对不上的地方。use_rules控制是否启用规则扩展做对照实验时把它在 true/false 之间切换就能得到“纯字典 vs 字典规则”的两组数据。concurrency是并发数纯 Python 版其实用不上但如果你把哈希计算换成多进程或外部工具这个参数就决定跑多久。report_out指定结果落盘位置方便后面写报告直接引用。3.3 一次完整运行与结果解读把靶子造好、配置填好运行顺序是固定的先生成哈希再跑破解最后出报告。python src/hash_gen.py data/targets/hashes.txt python src/dict_attack.py --config config.yaml python src/report.py --config config.yaml第一条把 5 条测试口令的哈希写进文件第二条读配置、跑字典加规则、把命中结果写到内存并落盘第三条读命中结果算破解率、平均耗时、命中口令的长度分布导出 CSV。跑完你会看到类似“5 条中命中 4 条破解率 80%其中 3 条来自规则扩展”的输出。这个 80% 不是让你炫耀的数字而是报告里要解释的对象剩下那条为什么没破是字典没覆盖还是它本身够强把这个问题回答清楚作业的深度就出来了。提示跑之前先确认hashes.txt里每行只有一个哈希混入空行或注释行会让比对逻辑把整行当哈希处理表现为“明明字典里有却破不出来”。4. 避坑与排查那些让破解率归零的细节4.1 现象命中数为 0但字典里明明有对应口令原因几乎总是编码或换行不一致。Windows 下生成的字典带\r\nstrip()能处理但如果哈希文件是用另一种编码写的或者生成哈希时用了utf-8而读取时默认了系统编码字节就对不上。解决方法是统一在读写时显式指定encodingutf-8并且在比对前打印一条候选的哈希和靶子哈希做肉眼对照。我吃过一次亏排查了半小时才发现是生成时口令末尾多了个空格。4.2 现象加盐后破解率断崖式下跌怀疑代码写错这不是 bug是加盐机制的正常效果。盐让相同的口令产生不同哈希字典里的预计算全部失效。正确的处理不是去改代码“修好它”而是在报告里把无盐和有盐两组结果并列说明盐的作用。如果作业要求必须破加盐场景那得先拿到盐值再按“盐口令”的规则重新生成候选这属于另一条攻击路径不能混在纯字典攻击里讲。4.3 现象规则扩展后内存暴涨或跑得极慢apply_rules对每个词生成十几个变体字典十万行就是上百万候选全塞进列表会吃内存。解决方法是改成生成器边算边比对不保留全部候选def iter_candidates(word: str): yield word yield word.capitalize() yield word.upper() for d in 0123456789: yield word d把return list换成yield内存占用从“候选总数”降到“常数级”。这个改动在字典小的时候看不出差别字典一大就是能不能跑完的区别。4.4 现象机器学习模块报维度不匹配训练时用fit_transform预测时却用了新的TfidfVectorizer实例词表对不上维度自然不一致。正确做法是把训练好的vec和clf一起保存joblib.dump预测时加载同一个vec做transform。另一个常见原因是训练集里出现了预测集没有的字符 n-gram这时transform会静默忽略表现为预测结果全偏一类需要检查训练样本是否覆盖了足够的字符组合。4.5 现象报告里的耗时数字不可信用time.time()包住整个破解循环把字典读取、规则生成、哈希计算全算进去得到的数字没法横向比较。我一般会分段计时字典加载、候选生成、哈希比对各记一个报告里分开列。这样当别人问“为什么你的方案快”你能指出快在哪一段而不是笼统说“优化了”。5. 二次开发把作业改成一个能复用的口令强度评估工具这份资源的骨架其实已经具备一个小型评估工具的雏形改造方向不是加更多破解算法而是把“攻击视角”转成“防御视角”。具体做法是保留hash_gen和dict_attack作为验证手段把ml_predict扩展成主入口输入一批口令脱敏后输出强度评分和风险提示。改造时我建议先动配置层把config.yaml拆成attack.yaml和assess.yaml两份前者管破解实验后者管评估流程避免两套逻辑互相污染。第二个改造点是把规则引擎参数化。现在apply_rules里的替换表和数字追加是写死的改成从 YAML 读规则列表就能在不改代码的情况下换一套变形策略做 A/B 对照也方便。第三个点是报告层report.py目前只输出 CSV可以加一个 Markdown 模板把破解率、命中分布、模型判弱比例渲染成一段可直接贴进文档的结论省掉手工整理的时间。验证改造是否成功我习惯用一组固定的小样本做回归5 条已知弱口令、5 条随机强口令跑完看弱口令是否全部被判弱、强口令是否误判。这个样本集不追求统计显著性只保证每次改动后行为可预期。下面这张表是我常用的对照维度维度改造前改造后目标规则来源代码写死YAML 可配评估入口无assess.py独立入口报告格式CSVCSV Markdown回归样本无10 条固定样本最后说个我自己的教训。早些年做类似实验我总想一步到位把字典、规则、模型全串起来跑结果任何一环出问题都定位不到只能从头重跑。后来我强制自己每加一个模块就先单独跑通、单独出数确认它自己的输入输出对得上再往主流程里接。这个习惯让我在后来的项目里少走了很多弯路——口令破解这类实验最怕的不是算得慢而是算完了不知道哪个环节在起作用。希望这套拆法能帮到你拿到资源后先跑通最小闭环再往上加东西。本文还有配套的精品资源点击获取