速查在线工具箱口令强度与安全速查
密码强度到底看什么、为什么「长度比复杂度重要」、口令该怎么生成与保管、双因素认证能挡住什么。
密码强度常被简化成「有没有大小写加数字加符号」，但这个说法会产生误导：P@ssw0rd 这类看似复杂的密码，早就出现在各种字典里，实际强度远不如一个更长的随机短语。
真正决定强度的是「猜中它需要尝试多少次」，这由长度和字符空间共同决定。理解这一点，就能解释为什么现代建议是「长而随机」优于「短而复杂」，以及为什么双因素认证比把密码设得更复杂更有效。
1强度由什么决定
密码强度可以用「熵」来量化：熵越高，可能的空间越大，猜中所需的尝试次数越多。长度和字符种类共同决定熵。
| 因素 | 影响 | 示例对比 |
|---|---|---|
| 长度 | 每增加一个字符，可能空间成倍增长，是最有效的杠杆 | 8 位纯小写约 2 千亿种，12 位约 95 万亿种 |
| 字符种类 | 扩大字符集也能提升强度，但增长慢于长度 | 同样是 8 位，加入大写数字符号可显著提升 |
| 随机性 | 来自字典、规律或键盘路径会大幅削减实际强度 | qwerty2025 与同等长度的随机串差距巨大 |
| 是否已在泄露库中 | 已泄露的密码等于零强度，无论看起来多复杂 | 含常见词汇或常见替换的密码直接排除 |
| 复用情况 | 一个站点泄露会波及所有使用同一密码的账号 | 这也是撞库攻击能大规模得手的原因 |
| 可猜身份信息 | 生日、姓名、手机号等会被优先尝试 | 包含个人信息的密码应视为弱密码 |
「复杂度要求」的历史来源是为了对抗简单的字典攻击，但研究发现用户会以可预测的方式满足这些要求（比如首字母大写、末尾加 1 和感叹号），实际增益有限。所以现行的主流建议已从「强制复杂度」转向「保证最小长度 + 检查是否在泄露库中」。
2常见弱密码模式
攻击者的字典里排在前面的就是这些模式。任何一条命中，都意味着密码实际强度远低于表面。
| 模式 | 举例 | 为什么弱 |
|---|---|---|
| 常见词汇 | password、admin、iloveyou | 在通用字典里排最前，瞬间被尝试 |
| 键盘路径 | qwerty、1qaz2wsx、asdfgh | 键盘相邻键位的路径是固定枚举的 |
| 数字序列与重复 | 123456、888888、abcabc | 重复与顺序是字典的高频项 |
| 词语 + 年份 | spring2025、company2024 | 「词 + 年份」是极常见的变体规则 |
| 常见替换 | P@ssw0rd、Adm1n | 字母替换规则（a→@、o→0）已被字典收录 |
| 首字母大写 + 末尾符号 | Welcome1! | 为满足复杂度要求而形成的固定套路 |
| 个人信息 | zhangsan1990、手机号后六位 | 社交工程可直接获得，字典会优先尝试 |
| 单一字符类型加长 | aaaaaaa123456 | 虽然长，但结构可预测，有效熵很低 |
「在泄露库里出现过」是判断密码安全性最强的一条标准，优先级高于长度与复杂度。一个站点的密码策略里如果能接入泄露库比对，效果通常比强制用户加符号更好。
3暴力破解与撞库
两类攻击方式的目标都是「拿到密码」，但手段与防御重点不同。
| 对比项 | 暴力破解 | 撞库（凭据填充） |
|---|---|---|
| 手段 | 穷举所有可能组合，或按字典顺序尝试 | 用其它站点泄露的账号密码来尝试登录你的站点 |
| 目标 | 单个账号或站点的密码 | 批量尝试大量账号 |
| 前提 | 密码空间不大，或弱口令 | 用户在多个站点复用同一密码 |
| 速度 | 离线破解可达每秒数十亿次；在线受限于请求频率 | 在线请求，速率受服务端限制 |
| 防御重点 | 强制最小长度、检查弱密码、限制尝试次数 | 多因素认证、异常登录检测、强制密码不复用 |
| 关键事实 | 密码足够长且随机时，穷举在时间上不可行 | 只要一处泄露且复用，其它站点立刻失守 |
离线破解与在线尝试的差距极大。攻击者一旦拿到哈希数据库，就可以在自己的硬件上无限次尝试，所以「密码够不够强」这个问题的真实答案，取决于攻击者拿到哈希后需要多久。这也是为什么服务端要花力气保护哈希数据库（用慢哈希 + 加盐），而不只是要求用户设复杂密码。
4生成与保管密码的正确做法
- 用长随机短语
- 由多个随机词组成的口令（如四个随机词拼接）长度足够、熵高且相对好记，是兼顾安全与可用性的方案
- 或用随机字符串
- 密码管理器生成的随机字符串强度最高，代价是必须依赖管理器来记忆
- 每个站点不同
- 这是避免一损俱损的关键。密码管理器的核心价值就在于让这件事变得可行
- 用管理器保管
- 把密码交给专门的密码管理器，主密码设得长且唯一，其余交给工具生成与填充
- 开启双因素
- 在密码之外再加一层验证，这是性价比最高的安全措施
- 定期检查泄露
- 关注自己邮箱是否出现在已知泄露事件中，及时更换受影响站点的密码
- 避免不安全保存
- 不要把密码写在明文记事本、聊天记录或邮件里；也不要在多个设备上明文同步
5双因素与通行密钥
当密码本身可能泄露时，第二层验证就成了最后防线。不同形式的第二因素强度差别很大。
| 第二因素 | 形式 | 强度 | 说明 |
|---|---|---|---|
| 短信验证码 | 手机短信 | 较低 | 存在短信拦截、号码转移与 SIM 卡劫持风险，但仍明显强于纯密码 |
| 身份验证器 App | 本地生成动态码 | 较高 | 基于时间的一次性密码，不依赖短信通道 |
| 推送确认 | App 内点击确认 | 较高 | 注意防范「疲劳攻击」，不要随手确认陌生登录 |
| 硬件安全密钥 | 实体密钥 | 最高 | 能抵御钓鱼，因为验证与访问的域名绑定 |
| 通行密钥（Passkey） | 设备内置密钥 | 最高 | 基于公私钥，私钥不出设备，天然抗钓鱼且免记密码 |
| 恢复码 | 一次性备用码 | 取决于保管 | 开启双因素后务必保存恢复码，否则设备丢失将无法登录 |
第二因素的价值在于「攻击者拿到密码后仍然进不来」。因此在做安全评估时，开启双因素通常比把密码从 12 位加到 16 位更有意义——前者改变的是攻击者能不能得手的结论，后者只是拖延时间。
看完就能用的站内工具
全部工具总览 →关于「口令强度与安全速查」的常见问题
密码应该设多长才安全？
现代建议的最小长度是 12 到 16 个字符，而且优先级上「长度」高于「复杂度」。原因是每增加一个字符，攻击者需要尝试的可能空间就成倍增长，而加入更多字符种类带来的增长相对有限——比如把 12 位纯小写扩展为包含大小写数字符号，空间增长约几百倍，而把长度从 12 提到 16，空间增长约五十万倍。所以更长更划算。当然更关键的前提是这个密码不在泄露库里、且没有明显规律。如果使用密码管理器生成的随机串，长度可以直接往 16 到 20 位以上设。
为什么 P@ssw0rd 这种密码不安全？
因为它的「复杂」是可预测的。这类密码建立在固定的替换规则上（a 换成 @、o 换成 0、i 换成 1），而攻击者的字典早已收录了这些规则的组合，P@ssw0rd 几乎肯定在常用密码列表里。也就是说，它看起来符合「大小写加数字加符号」的要求，但实际可搜索空间远小于它的字符长度所暗示的。这类密码的教训是：复杂度只有在不可预测时才有价值。与其构造复杂的替换，不如选择一个足够长、没有规律的随机串或随机词组合。
多因素认证能完全防止账号被盗吗？
大幅降低风险，但不是绝对。多因素的价值在于即使密码泄露，攻击者仍然缺少第二因素，因此无法直接登录，这能挡住绝大多数自动化撞库与凭据填充攻击。但仍有几类绕过方式需要注意：一是「疲劳攻击」，攻击者反复发送登录确认请求，期待用户不耐烦地点了同意；二是钓鱼页面实时转发，把用户输入的内容和动态码一起转发给真实站点；三是短信验证码可能被拦截或通过补卡转移。所以推荐的顺序是：优先使用硬件安全密钥或通行密钥（它们与域名绑定，能抵御钓鱼），其次用验证器 App，短信验证码作为最低限度的兜底。
密码管理器安全吗？把密码都放一个地方会不会更危险？
在绝大多数情况下，用密码管理器比不用更安全。核心原因是它解决了「密码复用」这个最大的风险点——人工记忆很难为几十个站点l各自维护一个高强度随机密码，结果往往是一个密码走遍天下，任何一处泄露都会连锁失守。密码管理器把所有密码加密保存在本地或受保护的云端，你只需要记住一个主密码，其余由工具生成与填充。风险确实集中到了主密码上，所以要把主密码设得足够长且唯一，并配合双因素认证保护管理器账号本身。相比之下，「不用管理器但到处复用弱密码」的总体风险要高得多。
继续查：相关内容
全部速查 →内容说明：本页速查数据由本站自行整理，事实性内容以对应官方规范与文档为准，未复制第三方速查表或百科的表述。数据最后核对日期：2026-10-05。若发现错误或已更新的标准，欢迎通过页脚反馈入口告知。