简介这是一份基于 Python 的密码强度检查器源码包面向 Python 入门开发者与安全方向学习者用于理解如何通过代码评估用户密码的安全性并快速应用到登录注册等场景。核心脚本提供密码常见维度的检测与评估内置基础强度判断逻辑可在此框架上扩展自定义策略。压缩包共 5 个文件整体仅约 4KB包含 Python 主程序、依赖说明文本、README 文档以及许可证和 Git 忽略配置结构简洁目录层级清晰既适合作为轻量级安全工具参考也适合作为课堂练习或开源项目入门素材。已有 954 人学习下载表明该示例在同类轻量级安全脚本中具有不错的参考性与关注度。通过阅读源码读者可掌握字符串处理与条件判断在密码校验中的应用并快速获得一个可运行的密码检查脚本。1. 一个密码强度检查器解决的到底是什么问题去年我在某公司帮人收拾一个内部系统的注册模块线上反馈一直说“注册弹窗太烦”打开日志一看密码框永远在提示“密码强度不足”而用户明明输入了一串 20 位的混合字符。问题出在哪检查器只数了字符种类长度一超就当强密码压根没看字符分布和常见弱模式。那一刻我就意识到市面上大多数密码强度检查器都是“样子货”看起来在评估实则连密码到底弱在哪都没算清。标题里的“密码强度检查器”不是一个教你背单词的科普玩具它是个给开发者用的代码组件接受一个密码字符串输出强度等级必要时给出改进建议。它解决的是注册、改密、找回密码这些表单场景里的“弱口令校验”问题适合后端工程师、全栈开发者以及任何需要自己做认证体系的团队。这篇文章会带你从原理走到实现再走到避坑落地一个能直接接进表单的 Python 检查器。2. 强度检查的原理拆解规则打分与信息熵该怎么选2.1 先理解“强度”指的是什么攻击成本的可量化估算“密码强度”这四个字在工程上当它等于“破解成本”。一个密码在攻击者手里被离线穷举、字典攻击、暴力破解打穿需要付出多少计算量。成本越高强度越高。这里有一个关键前提密码本身是字符串你没法只看它一眼就说出“这个密码很强”你能算的是它“猜中的期望次数”或者说“分布的熵”。一个密码的熵值计算方式是 log2(字符池大小^长度)也就是长度乘以单字符熵。字符池越大、长度越长熵越高。比如纯小写 26 个字符8 位密码的熵就是 8 * log2(26)约等于 37.6 比特。加上大小写数字符号池子变成 958 位密码熵约 52.6 比特。这个数字本身已经能说明问题同样是 8 位纯小写和混合字符之间的破解成本差了好几个数量级。但注意这是“理想随机分布”下的熵值上界人类生成的密码根本达不到这个上界所以要么接受“用上界评估、用规则修正”要么就得引入字典和 Markov 模型成本一下子上去了。2.2 规则打分最常见但注定偏弱的实现路径国内外的注册表单里满屏都是规则打分器有小写字母加 1 分有大写字母加 2 分有数字加 3 分有符号加 4 分长度超过 8 加 5 分最后总分映射到“弱/中/强”。这种实现写起来 20 分钟跑起来也快但它有几个致命的裂缝。第一“Pssw0rd”这种字符串长度 8、大小写混合、有数字有符号规则打分轻松上 8 分判成强密码。可它是个不折不扣的键盘路径变形词常见程度能排进字典前一百。规则看不到“常见模式”。第二规则打分天然不解释“为什么强”和“有多强”。用户看到“强”字但系统给不出“按照当前算力在线猜测需要约 7 年”这种可感知的量化结论。第三分数阈值一旦拍脑袋定下来后续维护就是玄学产品改一版要求阈值就得跟着改没有理论支撑。2.3 我的选择以熵值为主、规则降级为辅的混合判定我会这样设计先跑一组规则过滤器把字典词、键盘序列、重复字符、连续递增这类“人类常见弱模式”直接判为弱通过规则过滤的字符串再进入熵值评估按熵区间映射强度同时把熵值折算成估算破解时间给用户看。这套策略的逻辑是规则负责抓住“统计上高频的坏样本”熵值负责度量“对未知攻击者的抵抗成本”。两者各管一段互不越权。熵值计算有个边界必须说清楚我算的是“理想随机的上界熵”。一个用户可能把“qwerty123456”拆成 12 位池子 95 的字符串去算熵得到约 78 比特漂亮得很但它是键盘序列。所以规则过滤必须跑在熵值前面。反过来一个 20 位随机大小写加数字的密码规则可能抓不出毛病熵值也能给到 100 比特以上这才配叫强密码。这个先后顺序不能反反了就是“先给高分再抓作弊”用户体验极差。3. 用 Python 写一个最小可运行的强度检查器3.1 数据结构先定义字符类型与可复用常量实现不依赖第三方库Python 3.8 标准库足够。先定义字符池常量和基础类型。注意符号集不要自己手敲字符串直接用 string 模块避免漏字符。import string import math import re # 每个字符类别的池子后续熵值计算直接取集合大小 LOWER set(string.ascii_lowercase) UPPER set(string.ascii_uppercase) DIGIT set(string.digits) SYMBOL set(string.punctuation) ALL_PRINTABLE LOWER | UPPER | DIGIT | SYMBOL # 常见弱模式的正则键盘横向序列、重复三次以上、连续递增递减 WEAK_PATTERNS [ re.compile(r0123456789), re.compile(rqwerty|asdf|zxcv, re.IGNORECASE), re.compile(r(.)\1{2,}), re.compile(rabcdefghijklmnopqrstuvwxyz), re.compile(r(?.*password)(?.*\d), re.IGNORECASE), ]这里的常量设计是把“字符类别”和“字符池集合”拆开因为后面熵值计算需要的是池子大小而不是当前密码里出现了哪些类别。正则里的qwerty|asdf|zxcv是覆盖键盘横向序列的最简方案覆盖不了所有布局但能挡住绝大多数顺手输入。3.2 核心函数熵值计算与强度判定强度判定做成两个函数一个算理想熵上界一个把熵映射到强度字符串。这里有一个需要较真的地方len(password)和len(set(password))的含义完全不同。前者是长度后者是去重后的字符种类数。强度评估必须把长度和池子大小同时纳入否则长度减半、种类翻倍熵值可能不变实际感受却差很多。def estimate_entropy(password: str) - float: 计算密码的理想熵上界。 逻辑说明 1. 统计密码用到了哪几个字符类别把对应池子合并求出池子大小。 2. 池子大小决定单字符携带的信息量log2(pool_size)。 3. 总熵 长度 * 单字符熵。 4. 如果密码包含非可打印字符直接按未知池处理熵降级。 if not password: return 0.0 pools [] for char in password: if char in LOWER: pools.append(LOWER) elif char in UPPER: pools.append(UPPER) elif char in DIGIT: pools.append(DIGIT) elif char in SYMBOL: pools.append(SYMBOL) else: # 非可打印字符无法归入常规池视为未知拉低熵 pools.append(set()) union_pool set().union(*pools) if pools else set() if not union_pool: return 0.0 return len(password) * math.log2(len(union_pool)) def password_strength(password: str) - dict: 主判定函数返回结构化结果。 # 规则层命中常见弱模式直接判弱不进入熵值评估 for pattern in WEAK_PATTERNS: if pattern.search(password): return { score: weak, entropy_bits: 0, crack_time_estimate: 秒级, reasons: [命中常见弱模式键盘序列/重复/字典词], suggestions: [避免键盘序列和连续重复字符], } # 长度硬下限少于 8 位直接弱 if len(password) 8: return { score: weak, entropy_bits: estimate_entropy(password), crack_time_estimate: 秒级, reasons: [长度过短抛离池子大小之外], suggestions: [至少使用 12 位密码], } entropy estimate_entropy(password) if entropy 45: score weak elif entropy 60: score medium else: score strong # 破译时间估算按熵值离线攻击每秒 10^10 次猜测 seconds 2 ** max(entropy, 0) / 1e10 if seconds 60: crack_time 秒级 elif seconds 3600 * 24: crack_time f{seconds / 3600:.1f} 小时 else: crack_time f{seconds / (3600 * 24):.1f} 天 return { score: score, entropy_bits: round(entropy, 2), crack_time_estimate: crack_time, reasons: [f字符池大小 {len(set(password))}长度 {len(password)}], suggestions: [如果这是真实密码建议继续加长或增加字符类别], } if __name__ __main__: for pwd in [123456, Pssw0rd, k#9Lp2xQ!vZ8, qwerty123456]: print(pwd, password_strength(pwd))这段代码有三个关键参数需要你知道怎么改。第一entropy_bits的阈值 45 和 60 不是标准答案45 比特大概对应纯小写 10 位密码60 比特对应混合字符 10 位以上。你可以按业务安全等级调高或者调低但不能同时调低于 40否则长度 8 的纯小写密码会被放过去。第二crack_time_estimate里的1e10是猜测速率表示攻击者每秒做 100 亿次 SHA-256 计算。如果你做的是加盐慢哈希这个数字要往下降两到三个数量级估算时间会更乐观。第三WEAK_PATTERNS是正则列表按需往里面加指纹比如重复单词、公司名年份这种组合正则的检索效率在密码长度一般不超过 64 的前提下足够应付。3.3 常见误用长度、熵值、破译时间三个指标混为一谈写检查器最容易犯的错是混用这三个指标。有人拿“密码长度超过 12”当成强密码的依据完全不管字符池大小。一个 12 位纯数字密码的熵约 39.8 比特比一个 10 位混合字符密码的熵 60 比特差了一个数量级。也有人在展示给用户的文案里把“熵值 85 比特”和“约需 28 万年”并列展示但前者是理想随机分布的上界后者是按上界算出来的用户一旦真用了“ILoveYou2000”这种字符串估算时间就是完全失真。成熟的工程做法是展示长度建议和字符类别建议把熵值和破解时间折算藏在后端的日志里避免误导。4. 做成命令行工具输入交互、回显控制与退出码设计4.1 用 argparse 与 getpass 实现安全的密码输入检查器代码要落地第一件事是给它一个命令行外壳方便开发环境和 CI 里直接用。核心点是密码输入不能用明文参数传否则 shell 历史记录会留下密码这个习惯必须从第一天就立住。用getpass.getpass()做无回显输入只用argparse处理非敏感选项。import argparse from getpass import getpass from strength_checker import password_strength # 上一章的模块 def main() - int: parser argparse.ArgumentParser(description密码强度检查器) parser.add_argument(--quiet, actionstore_true, help只输出等级不加建议) parser.add_argument(--format, choices[text, json], defaulttext, help输出格式) parser.add_argument(--stdin, actionstore_true, help从标准输入读密码脚本用) args parser.parse_args() if args.stdin: password input().rstrip(\n) else: try: password getpass(请输入待检查的密码: ) except (EOFError, KeyboardInterrupt): return 130 if not password: return 2 result password_strength(password) if args.format json: import json print(json.dumps(result, ensure_asciiFalse, indent2)) else: print(f强度: {result[score]}) if not args.quiet: print(f熵值(理想上界): {result[entropy_bits]} 比特) print(f估算破解时间(离线,1e10/s): {result[crack_time_estimate]}) for s in result[suggestions]: print(f建议: {s}) return 0 if result[score] ! weak else 1 if __name__ __main__: raise SystemExit(main())这个 CLI 有四个设计值得你抄走。第一--stdin是为了脚本环境准备的在 CI 测试里可以echo xxx | python cli.py --stdin --format json不弹交互输入。第二退出码 0 和 1 分别表示“非弱密码”和“弱密码”上层脚本可以据此写断言。第三--quiet控制输出长度给 shell 脚本判定用的不至于被大段建议刷屏。第四参数--format json支持结构化输出给上层 Web 服务调用时直接用json.loads解析不需要再去抠文本。4.2 输出设计强度等级、熵值、改进建议的呈现角度输出不能只给等级要给可执行建议。用户看到一个“中”字不会有任何动作看到“建议增加长度到 14 位以上”才可能改密码。所以在 text 模式下我把建议单独打印一行并且措辞永远用“建议”而不是“必须”因为你不知道用户是不是在创建密码也许他是在校验一个已经用了三年的旧密码过度强硬会打断流程。这里有一个容易被忽略的点--quiet模式下仍然输出了强度:这一行没有完全静默。原因是“完全没输出”会让脚本难以判断只输出等级这一个词脚本端grep解析也方便。如果你有更严格的机器可读需求直接上 JSON 格式文本格式就是给人看的。4.3 CLI 参数解析与退出码的联动边界退出码分档0 非弱、1 弱、2 无输入、130 中断。这四个值已经覆盖了使用场景。有人会把“中”也映射成 0我是支持的因为业务上中等强度密码通常可以放行只提示风险。如果是强安全要求的系统把阈值上移一格让中等强度也返回非 0后端直接拦截。5. 密码强度检查器的坑不止是误判5.1 常见误报把“Pssw0rd”判成强密码现象一串 8 位、大小写数字符号齐全的密码熵值算出来 50 多比特判定为“中”甚至“强”。原因规则过滤没有覆盖“单词变形”类弱模式。Pssw0rd是password的 l33t 变体字符类别齐全但不属于常见键盘序列也没有重复字符所以默认正则找不出问题。解决把 l33t 变体规格化成明文再做字典匹配凑几个高频变体进WEAK_PATTERNS或者更优雅一些准备一个小字典文件把常见弱密码和变体写进去检查器启动时加载进内存。字典不需要大上千条就够拦下大多数人类习惯。5.2 常见漏报符号混入但长度不足现象用户输入Ab3!四个字符四个类别全占按规则打分勉强到中等熵值约 26 比特被放行了。原因规则打分给了“字符种类丰富”不少分数长度权重却不够。逻辑上这家伙比abcdefgh好一点但仍然挡不住任何离线穷举。解决把长度硬下限提到 8并且在长度小于 8 时不进入规则评分直接判弱。说白了长度是骨架字符种类是衣服骨架不对穿什么都没用。5.3 常见误用熵值算出来了但展示出来用户根本看不懂现象某系统把“熵值 78.5 比特”直接显示在注册表单附近用户一头雾水反而产生抗拒心理。原因熵值是给机器和开发者看的不是给用户看的。普通用户对“比特”根本没有直观感知。解决对外文案只说强弱等级和“建议加长”熵值和破解时间写进审计日志。如果产品非要展示用“与当前最强超算相比破解需要约 xxx 年”这种生活化描述但前提仍然是密码属于生成的强随机类型否则就是误导。5.4 常见踩坑中文输入的密码导致熵值评估失真现象某开发者在测试时输入你好世界123程序跑出来的字符池大小是 4判成弱密码但实际池子应该包含中文字符集真实熵值远高于估算值。原因字符池判断逻辑里中文字符落到了else分支被当成未知字符集池子大小为 0 或 1熵值被严重低估。解决至少要识别 Unicode 非 ASCII 字符并单独归成一个大池子比如统一按 0x4E00-0x9FFF 的中日韩统一表意文字区间处理。简化做法如果字符的 Unicode 码点大于 127就把池子大小至少定为 20902常用汉字范围。虽然不精确但不会离谱低估。5.5 常见翻车把“必须三种字符”当成强度标准现象某产品需求写道“密码必须包含大写、小写和数字”但上线后发现大量用户生成的密码是Ab1aaaaaaa长度 10 位字符种类齐全规则判定通过。原因强制字符种类只会让用户在最前面补一个满足规则的前缀后续全是重复或键盘序列。解决检查器不止要检查“有没有某种字符”还要检查“是否有连续重复超过三次”、“是否出现常见键盘序列”。在规则层把这一类拦截掉而不是只靠熵值。统计分布告诉你的现实是用户会想尽办法用最小成本补齐规则你没想到的模式他们总会想到。6. 进阶技巧把检查器改造成注册表单的可靠组件6.1 输入控件上的交互节奏别在每次按键时都跑全量检查密码检查器接进表单时最常见的错误是绑定input事件每敲一个字符就调用一次检查函数。密码长度超过 20、规则又复杂时前端交互会明显卡顿。我一般会做两层输入阶段只做极简规则检查比如长度提示在输入停止 300ms 后才调用完整评估。后端接口可以承受同步调用前端必须防抖这是体验和性能的平衡点。防抖的参数没有标准值300ms 是通用选择。如果检查函数里有字典匹配和多种长度扫描单次耗时可能会到几十毫秒防抖时间适当放宽到 400-500ms。6.2 返回结构化结果而不是布尔值很多团队直接把检查器封装成is_strong(password) - bool这是给自己埋坑。布尔值丢掉了“为什么弱”和“该怎么改”前端拿到False只能弹一句通用的“密码强度不足”用户不知道往哪个方向努力。正确做法是返回{score: weak, reasons: [长度过短], suggestions: [至少使用12位]}这种结构化对象。前端可以直接渲染建议列表后端可以按score字段决定是否拦截。这个设计也方便以后扩展。某天你要给不同安全等级的用户返回不同文案只需要在调用方加一个分支不需要改检查器内部。6.3 把检查器当测试工具用批量验证与回归最后分享一个我自己的习惯写一个包含弱密码、边缘密码、强密码的固定测试集每次改了检查器逻辑先跑测试集看判定结果有没有异常。测试集里至少包括空字符串、8 位以下密码、纯数字长密码、键盘序列、重复字符、带中文的密码以及一个 64 位高随机密码。跑一遍只要几毫秒但能守住前后一致的行为基线比上线后被用户反馈打脸好得多。我在某跨平台系统上就是这么干的。起初测试集里只有十来个用例后来每次收到误报反馈就往里面补一条。半年后测试集到了几百条检查器的误报率大幅下降。养成这个习惯之后我基本上不会直接改判定逻辑总是先加用例、再看失败、再改代码免得按下葫芦浮起瓢。希望帮到你。本文还有配套的精品资源点击获取