基于个人信息自动生成定制密码字典：Python脚本设计实战

做授权渗透测试和红队评估的朋友大概率都遇到过这种场景目标资产的弱口令问题摆在那里用通用字典跑一遍rockyou那几十G的字典砸下去出结果全靠运气。但你手上其实握着最优质的信息源——目标的姓名拼写、生日、手机号、邮箱前缀、常用ID甚至他在公开社交主页上晒过的宠物名字。与其拿海量通用字典大海捞针不如先把这些碎片化的个人信息组合成一份针对性的密码猜测字典再用它去撞目标系统。这个思路不算新但真正做到“自动化生成”的落地脚本并不多。我最近把整套流程整理成了一个Python脚本输入目标的基础信息自动拆解、组合、变异最后输出一份按优先级排序的定制字典。这篇文章把脚本的设计思路、核心实现、踩坑记录完整拆出来供有同样需求的朋友参考。丑话说在前面这套东西只能用于你有明确授权的测试目标比如自己搭的靶机、公司委托的评估项目或者做密码安全自查绝对禁止拿它去碰任何未授权的系统这是底线。1. 项目整体设计与思路拆解1.1 为什么个人化字典比通用大字典更值得做通用字典的价值是覆盖面广但代价是噪音极大。rockyou.txt有超过1400万条记录跑完一轮要很久而且绝大部分条目跟目标毫无关系。个人化字典的思路完全反过来不追求量追求“命中率”。一个真实世界里的密码大概率由本人熟悉的信息构成名字缩写、出生年月、手机尾号、配偶或子女的名字、纪念日、所在城市的拼音、喜欢用的ID以及这些元素的排列组合。从红队视角看个人化字典的真正优势有三个。第一是时间成本可控通常几万条到几十万条的量级在本地或者目标服务器上用hashcat或者hydra跑完只需要几分钟到几十分钟而通用大字典可能要挂机几小时。第二是规避频率限制很多系统有账户锁定策略高频尝试会触发锁定个人化字典量小能在触线之前完成更精准的测试。第三是贴合真实人类行为大部分人的密码习惯是“一个核心词根加一套固定变换规则”摸清这个规则比堆砌海量随机字符串有效得多。1.2 脚本的核心目标与适用场景写这个脚本前我给自己定了几条硬性标准。输入要足够灵活姓名、生日、手机号、邮箱、昵称、公司名、城市、纪念日、父母子女名字都能往里塞输出要足够智能不只是机械拼接还要有人类常见的密码构造逻辑性能要足够稳数据量评估、去重、排序都在内存里完成跑完不卡死结果要足够可用生成一份按可能性排序的字典文件方便直接喂给hashcat或者hydra。适用场景比较明确授权渗透测试中的口令安全检测、企业内部密码风险评估、红队模拟攻击中的初始立足点尝试。原理上也可以用于个人账户的安全自检——把自己公开过的信息丢进去看看能不能生成自己的“高危密码”从而提醒自己改密码。但请注意无论是哪种场景前提都是获得授权或确认是自有资产这个边界不能突破。1.3 技术选型与方案取舍脚本主体用Python实现原因很直白字符串处理能力优秀、生态成熟、跨平台而且做原型迭代特别快。密码生成的核心是排列组合逻辑Python的itertools模块天然支持各种笛卡尔积和排列枚举省去很多手写循环的麻烦。生成过程用多进程池来吃满CPU跑几十万条组合也就是秒级的事。至于字典的“智能排序”我采用的方案是给每类信息设置基础权重组合时累加权重最后按权重降序排列。这个设计比纯字典序输出更贴近实际——一个“名字生日年份特殊符号结尾”的组合命中概率远高于“随机字符生日名字”的稀奇古怪组合权重方案就是在模拟这种人类密码构造倾向。2. 信息分类体系与密码构造规则2.1 个人信息分类与字段设计脚本的第一个核心模块是信息分类。我设计了几个基础字段类别每类都有对应的编码器负责把原始信息转换成候选词根库。姓名类记录中文姓名、拼音全拼、声母缩写、英文名。这里有个细节姓氏和名字要分开存因为组合时它们常常被拆开使用比如“zhangsan”、“zs1988”、“zhang.san.2010”。生日类支持多种日期格式年月日、年月、日月分别记录。1988-06-15会拆成1988、0615、1506、88、06等片段年份的两位和四位格式都要保留。手机号类记录完整号码、后四位、后六位、前三位通常代表运营商和地区也会有人拿来当密码前缀。邮箱类提取前面的部分再去掉点、下划线、数字得到纯字符前缀。邮箱前缀往往是目标最常用的ID。昵称与ID类社交账号、游戏ID、论坛ID这些是最容易被忽视但价值极高的词根很多人会把同一个ID用十年。地点类城市拼音、小区名、公司名、学校名。这些信息常作为密码词根或中间段出现。特殊数字类纪念日、车牌号、QQ号、门牌号、工号。这类数字通常是纯数字密码的主要来源。基础符号表常见特殊符号位如!、、#、$、%、、*等以及它们的键盘相邻符号。2.2 密码构造规则引擎有了词根库下一步是定义密码的构造规则。我把规则分为基础组合、扩展变异、键盘序列三大类。基础组合规则覆盖最常见的密码形态纯数字日期、姓名拼音生日年份、姓名缩写特殊符号数字、英文名手机号尾号、ID年份等。这部分是脚本的核心产出量级最大。扩展变异规则处理更复杂的情况大小写交替zhaNgSan、ZhangSAN、首字母大写、单词反转、字母替换a-, s-$, o-0, i-!、双写核心词根、在密码头尾追加高频符号。这些变异常常是通用字典覆盖不到的死角。键盘序列规则单独提出来说因为它不依赖个人信息但常被当成密码元素混在个人化密码里比如“qwerty”、“asdfgh”、“1qaz2wsx”、“!QAZWSX”。这类序列可以作为词根与其他个人信息拼在一起也可以单独作为弱密码候选。2.3 组合爆炸的控制策略个人化字典最大的风险不是生成不了而是生成太多。三个词根库各自有几十个元素如果不加约束直接做笛卡尔积千万条数据瞬间生成跑起来反而拖慢速度。我采用的控制策略是组合深度限制。默认最多拼接三个词根三元组会做一次“意义合理性”过滤比如数字词根放在末尾更常见、名字词根放在开头更合理。再叠加最小长度和最大长度过滤默认8到24位。最后做全局去重和前缀数量统计。实际测试里一份中等规模的信息输入最终生成的字典量级可以控制在10万条以内既保留覆盖率又保证运行效率。3. 脚本实现与核心代码解析3.1 整体框架与目录设计脚本采用单文件结构方便部署和分发。整段逻辑分成四个部分config区负责参数配置和词根库初始化informations类负责信息录入与标准化generator类负责规则生成和权重评分main函数负责组装、去重、排序、导出。#!/usr/bin/env python3 # -*- coding: utf-8 -*- personal-wordlist-generator 基于个人信息生成定制化密码猜测字典 仅限授权安全测试与自有资产安全自查使用 在实际使用中我建议把这段脚本放在一个干净目录里和输出文件分开存放避免字典文件过大时读写混乱。脚本运行环境只需要Python 3.7以上不依赖第三方库把itertools、re、pathlib这些标准库用好就够。3.2 词根库构建与标准化词根库的构建是整个流程的地基。信息录入后先做标准化清洗这一步很重要因为原始输入通常带有脏数据全角空格、大小写混乱、中文标点、重复字符。清洗不到位后面生成的密码候选里就会混入大量注定无效的格式。def normalize_token(raw): raw raw.lower().strip() raw re.sub(r[\s\u3000], , raw) raw re.sub(r[\W_], , raw, flagsre.UNICODE) return raw以姓名为例录入“张三 / Zhang San / San”之后脚本会同时生成“zhangsan”、“zhang”、“san”、“zs”、“zhs”这几种词根分别归入到全拼、名字、缩写三个子库。日期数据会按“19880615”、“1988”、“0615”、“88”四种形态存储年份的两位格式单独保留是因为很多密码规则里它充当短数字后缀。手机号拆成“138xxxx6688”、“6688”、“138”三段其中尾号权重最高。3.3 生成器与权重评分生成器的核心是一个有序的组合枚举过程。我对每一类规则设定一个基础权重生成的密码累加权重值。规则越贴合真实人类行为权重越高。比如“名字全拼生日年份”权重设为90“名字缩写特殊符号手机尾号”权重设为95而“城市拼音邮箱前缀键盘序列”权重设为75。规则权重会跟词根本身的权重叠加比如生日年份作为词根时权重天然高于随机数字。# 权重组示例 WEIGHT_RULES { name_year: 90, initial_special_tail: 95, en_name_city: 70, plain_pure_digit: 60, }生成过程用itertools.product枚举所有组合然后根据组合形态匹配对应规则累加权重再进入长度过滤和去重阶段。这里有一个调优技巧权重分不是越高越好关键是让不同规则之间有梯度否则排序结果拉不开差距。我调了几轮把权重范围定在60到95之间效果最好。3.4 去重、排序与导出去重不是简单set()就完事还涉及一个常见陷阱大小写变体。比如“ZhangSan1988”和“zhangsan1988”在规则上是两条不同密码但在实际命中场景里前者出现的概率远高于后者。脚本里对这类变体不作合并只是统一记录原始形态保证排序时完整体现规则权重。最终导出采用“权重降序、ASCII字典序兜底”的双重排序。输出文件按行存储每行一个候选密码。默认文件名为target_wordlist.txt。考虑到后续可能直接作为hashcat的字典输入我特意没有加任何格式头或注释行纯文本就最干净。4. 实操演示与典型用例拆解4.1 用例给一台授权靶机生成字典拿一个真实授权的测试环境演示一下。假设我通过公开信息搜集整理出目标应用管理员的一组字段姓名拼音“wangwei”生日“1985-11-23”手机尾号“8867”常用ID是“weiw”邮箱前缀“wangwei”,所在城市“hangzhou”。这些信息在常规信息收集阶段很容易拿到。运行脚本后生成的字典里能看到几类典型候选。第一类是纯拼音加数字拼接比如“wangwei1985”、“weiw1123”、“wangwei8867”。第二类包含特殊符号比如“Wangwei1985”、“ww#1123”、“Weiw_8867”。第三类是键盘序列混搭“wangwei!#”、“weiwqwer”。整个字典生成量约两万条体积不到300KBhashcat跑MD5和NTLM模式的效率非常高几秒钟就能跑完全部候选。4.2 在Ubuntu环境下配合hashcat使用脚本本身跨平台但实际渗透测试里大多数配套工具链都在Ubuntu上跑我也顺便说下配合方式。先生成字典python3 personal_wordlist_generator.py -i info.json -o target_wordlist.txt接着确认目标哈希类型比如是WordPress的phpass哈希就在hashcat里选模式400hashcat -m 400 target.hash target_wordlist.txt --potfile-disable如果目标服务支持在线口令测试hydra配合字典也很方便hydra -l admin -P target_wordlist.txt target_ip http-post-form /login.php:user^USER^pass^PASS^:Invalid这里提醒一句在线测试必须额外注意频率限制和账户锁定策略即便有授权也要控制尝试速度加上-t 1参数让并发数降到1避免触发防护机制给目标造成不必要的麻烦。4.3 信息输入模板建议为了方便信息录入我把JSON配置格式设计得很直观。实际测试时团队里其他成员可以复用同一份模板往里面填不同的侦察结果。{ name: [wangwei, Wang Wei], birthday: [1985-11-23, 19851123], phone_tail: [8867], ids: [weiw, wangwei, ww_2018], emails: [wangweiexample.com], cities: [hangzhou], keywords: [admin, security], anniversary: [2014-10-01], special_chars: [!, , #, $, %, , *] }值得留意的是keywords字段可以重复填多个语义信息比如公司名称、部门花名、系统的英文代号这些信息在弱密码里出现的频率比很多人想象中高。5. 常见问题与排查技巧实录5.1 生成字典太大如何进一步压缩最常被问到的就是字典爆炸问题。我通常建议先跑一轮纯数字和纯姓名组合量级通常在千条以内用来快速试探最简单的那批弱密码。如果没收获再放开规则深度生成全量字典。实操里我习惯用参数控制规则集比如只跑“名字日期符号尾”这条最实用的组合链把这轮的命中率单独看。5.2 权重排序看起来不够合理需要调整脚本跑出来的字典排在最前面的候选不一定符合直觉。遇到这种情况别急着调权先看一眼生成日志里的组合记录确认是不是某个词根被错误清洗了比如全角字符没处理干净导致组合结果根本不会在真实系统里出现。如果词根没问题再调整规则权重表。我调整权重的一个套路是在小样本上跑一遍提取前200条人工过一遍看看哪些规则贡献的候选占据太多比例适当降权再跑来回两三轮就能收敛到比较合理的排序。5.3 编译错误和运行环境问题脚本只依赖Python标准库理论上不会有第三方包安装问题。常见报错集中在Python版本太老导致f-string语法不支持或者JSON配置里混入格式错误。我的建议是把运行环境锁定在Python 3.8以上遇到语法错误优先检查版本。另外在部分Linux发行版默认Python版本较低的环境里建议用python3 --version确认一下再跑。5.4 信息缺失时怎么办实战中理想情况少更多时候只拿到半个手机号、模糊的生日范围。我的做法是保留信息碎片本身比如只知道出生年份是“1985”那年份词根就只放“1985”不脑补月份和日期只知道手机号前三位是“138”就不强行生成完整号码。生成器会自动把已知片段和名字、ID等其他信息做组合即便信息不全也能产出不少有价值的候选。5.5 关于密码猜测工具的性能调优如果你的字典量级到了几十万条建议生成阶段就启用多进程。脚本默认用进程池的map分片处理组合生成任务在四核CPU的笔记本上十万级字典的生成时间能控制在十秒以内。瓶颈通常在写盘阶段尤其是机械硬盘上写几十万行文本会有明显延迟可以考虑先把输出暂存到临时文件再统一重命名减少目录碎片。6. 扩展思路与自动化集成方向6.1 与自动化信息收集流程打通字典生成的输入项完全可以由信息收集阶段自动输出。比如用脚本批量抓取目标在公开信息中暴露的邮箱前缀、社交ID、公司名自动转换成JSON格式喂给这个生成器形成“信息收集→词根提取→字典生成→口令测试”的自动化流水线。我在自己的评估流程里已经这么干了效率提升非常明显。6.2 引入规则模板的可视化配置代码里规则权重表的硬编码虽然灵活度不错但每次调整都得改代码重新跑效率偏低。我计划后续把规则权重和组合深度做成一个YAML配置文件运行时加载减少改代码的频次。如果团队成员里有人不熟悉Python改配置文件的成本远比改代码低。6.3 结合机器学习做语序建模再往远想一步现在这版脚本的排序依据是人工经验权重本质上是静态规则。真实世界里不同人群的密码习惯差异很大——年轻人更喜欢加emoji和特殊符号后缀年长用户更倾向纯数字或简单字母组合。如果能用一份脱敏的真实密码样本库训练一个小型语言模型让组合顺序依样本概率动态调整那生成出来的字典就真正“贴脸”了。这个话题我现在还在做实验后面有成熟结果了再单独写一篇详细分享。7. 安全边界与合规提醒最后这部分必须单独强调。密码猜测字典的生成本身是中性的技术但它天然是攻击性安全工具一旦用于未授权目标就是违法越界。我写这套脚本的定位是授权渗透测试与自有资产安全自查这个边界我全程都不敢放松。即便是做合法测试操作之前最好也确认一下合同或授权书里对该目标的测试范围是否包含口令测试避免越权操作。具体操作层面有几个细节必须小心不要对生产环境的高权限账号做在线爆破式尝试不要绕过多因素认证机制不要在没有明确书面授权的情况下扫描目标资产。在一个有防御体系的目标上这类行为很容易被安全团队当作真实攻击上报给自己带来麻烦。工具可以锋利但使用的人必须有分寸。按照我在实际项目里的操作习惯生成字典之后我会先在本地的hashcat环境里验证一遍把虚拟机的Windows和Linux账户哈希各过一遍确认无误再考虑是否进入目标环境的测试流程。整个过程每一步都留存执行日志和授权依据既是职业习惯也是自我保护的底线。