随机密码和可读密码该怎么选：四个单词并不自动等于够强

客服把 Wi-Fi 口令念给上门的同事，运维在共享键盘上敲路由器后台，开发给测试账号各发一串新密码——这三件事对「密码长什么样」的要求并不一样。第一、第二种必须手输，第三种几乎总会进密码管理器。很多人看过 xkcd 936 那幅漫画：Tr0ub4dor&3 难记却只有大约 28 bits，correct horse battery staple 四个常见单词却有大约 44 bits。于是「四个单词 = 够强」被当成通用结论。

漫画里的算法有一个前提：每个单词是从大约两千个常见词里均匀随机抽出来的（漫画按每词 11 bits 估算）。词表换成 100 个词，同样四个单词只剩大约 27 bits，比漫画弱一截，也明显弱于 16 位随机字符。本文不讲生成器按钮怎么点，只回答什么时候用随机字符、什么时候用可读密码，以及四个单词到底够不够。MyPassGen 两种模式都打开即用；随机模式默认 16 位，可读模式从内置 100 词表抽 3–10 个词。下面的数字你可以自己用计算器复核。

先问能不能交给管理器

NIST SP 800-63B-4（2025 年 7 月 31 日正式发布）把口令长度和「人怎么输入」拆开写。用作单因素认证时，验证方必须要求至少 15 个字符；只作为多因素里的一项时，最短仍不得低于 8 个字符。验证方还应允许密码管理器和自动填充，并在没有自动填充接口时允许粘贴。规范写明：管理器提高了用户选用更强口令的概率，尤其当它自带生成器时。

同一份文件还写了两件常被站点政策忽略的事：验证方不得再强制「必须混用大小写、数字和符号」这类拼写规则；也不得要求定期改密，除非有证据表明这条口令已经泄露。对选择哪种生成方式，含义很直接：能粘贴、能自动填充的场景，没有必要牺牲熵去迁就「好不好念」。必须手输时，才用单词降低敲错率，并用更多单词把熵补回来。

MyPassGen 随机模式允许 6–128 位，默认 16 位，对齐单因素 15 位这一量级；低于 8 位会提示安全性较低。这是生成器自己的范围，不是「6 位已经符合 NIST」。站点若只允许 8 位，你只能在该上限内取满，并尽量打开多因素，而不是假装 8 位随机串等于 16 位。

两种生成模型

随机字符和可读密码不是「同一种密码的两种皮肤」，而是两套计数方式。随机字符从字符池里逐位抽取：勾选大写、小写、数字和符号后，池子大小就是这几类的合计。可读密码从一张固定词表里抽单词，再用分隔符拼起来。攻击者若知道你用的是哪张表、抽了几个词，猜测空间就是「词表大小的单词数次方」，不是「看起来有多长的字符串」。

随机字符：按位累加

均匀随机时，熵近似为 长度 × log2(字符池)。MyPassGen 默认勾选四类时，大写 26、小写 26、数字 10、符号 !@#$%^&*()-_=+[]{} 共 18 个，合计 80。16 × log2(80) ≈ 101 bits。只开字母和数字（62）时，16 位大约 95 bits。长度掉到 8 位、仍用 80 的池子，只剩大约 51 bits——这就是「短而复杂」看起来唬人、数量级却上不去的原因。

可读密码：按词累加

均匀随机时，熵近似为 单词数 × log2(词表大小)。Arnold Reinhold 的 Diceware 和电子前哨基金会（EFF）2016 年公布的长词表都是 7,776 个词，等于五枚六面骰子的组合数 6⁵。每词约 12.9 bits；EFF 建议用六个词，大约 77.5 bits。漫画里的四个常见词按每词 11 bits 计，大约 44 bits——那是另一张更大的「常见英语词」表，不是 100 词的短表。

抽取必须用符合密码学要求的随机源。Crypto.getRandomValues 被 MDN 定义为获取符合密码学要求的安全随机值；同一套文档把 Math.random() 标成不提供密码学安全随机数，并写明安全相关用途应改用 Web Crypto。用 Math.random() 拼出来的「随机密码」或「随机单词」，在模型上就不能按上面的公式自称满熵。

熵怎么算：先数词表

同一句「四个单词」，分母不同，结果可以差一倍。log2(100) ≈ 6.64，所以 100 词表上四个词约为 27 bits；log2(7776) ≈ 12.92，7776 词表上四个词约为 52 bits；漫画按每词 11 bits，四个词约为 44 bits。少报词表、只报单词数，是把可读密码写强的最常见手法。

插入一个数字或一个符号，只能再叠加有限的选择：十个数字大约 3.3 bits，一小撮符号大约 3 bits。MyPassGen 可读模式若勾选插入数字或符号，页面估算会各加上大约 6 bits，这是偏宽松的内部标尺，不能理解成「加一个 ! 就接近 Diceware 六个词」。首字母大写按每个单词大约 0.5 bits 计，同样只是微调。要把 100 词表的可读密码抬到「强」这一档（内部阈值约 60 bits），需要把单词数加到 8–10 个，而不是只在四个词后面塞 1!。

自己选词更糟。歌词、电影台词、办公室里的项目名，都落在攻击者的短语表里，不能按「词表大小的四次方」计算。可读密码成立的条件是：词来自已知词表的均匀随机抽取，而不是你记得住的那句句子。

对照表：100 词、7776 词、随机串

下面这张表用同一套公式。100 词对应 MyPassGen 可读模式的内置表；7,776 词对应 Diceware / EFF 长表；随机串按 80 字符池。内部强度档位与生成器一致：约 40 bits 以下为弱，60 以下为中，80 以下为强，以上为极强。这是给自己看的尺子，不是对某块 GPU 的承诺。

读表时只抓两件事。第一，默认 16 位随机串在这张表上是最省事的「极强」：你不用记，管理器会填。第二，可读模式若停在四个词，它的数量级接近「短随机串」或「漫画里那条被改写的单词」，并没有因为好念就升级。必须手输时，把 100 词表用到 8–10 个词，或接受 Diceware 六个词的长度，而不是用四个词去对标 16 位随机。

NIST 单因素 15 个字符是长度下限，不是熵下限。15 位、80 字符池大约 95 bits，和默认 16 位同一档。四个常见英语单词即使按漫画的 44 bits 计算，也仍低于这条长度要求所对应的随机串。手输场景要同时满足「人敲得进去」和「数量级别掉队」，靠的是加词，不是加 @。

常见误区

「四个单词就是 xkcd 那条」不成立，除非词表和随机源都对齐漫画或 Diceware。只看到连字符隔开的英语单词，不能反推每词有 11 或 12.9 bits。

「可读密码一定比随机字符弱」也不成立。Diceware 六个词大约 77.5 bits，已经进入「强」；100 词表十个词大约 66 bits，也能到「强」。弱的是短词表加太少的词，不是「用了单词」这件事。

「加 123 和感叹号就能补强」对人类选的短密码几乎无效：这类后缀早已进字典。对均匀随机的单词串，多一个数字只加几个 bits，换不成两个额外单词。

「在线生成器既然能出可读密码，结果一定很强」取决于词表。有的页用 7,776 词，有的只有几百甚至几十个主题词。打开页面前先问：词表公开多长？随机源是不是 getRandomValues？生成结果有没有作为业务数据上传？口号不能代替这三项。

「HTTPS 已经保证密码不会泄露」只覆盖传输路径上的窃听。生成页若把结果 POST 出去，或把口令写进分析事件，HTTPS 仍然会把明文送到对方服务器。核对方法见浏览器里做加密，怎么当场核对明文没有上传：看 Network 里的请求行和请求体，而不是看锁形图标。

当场核对

下面这组步骤不依赖品牌承诺。用一条不会用于真实账户的口令做试验即可。

1. 打开生成页，选可读密码，单词数设为 4，生成一条。记下页面给出的强度档位和熵。按上表，100 词 × 4 应落在弱（约 27 bits）附近。
2. 把单词数改成 8 或 10，再生成。档位应上升；10 个词应接近「强」。不要改用自己想的四个词来「优化」结果。
3. 切到随机字符，长度保持默认 16，四类字符都打开，再生成。档位应为极强（约 101 bits）。把三条结果并排看：可读四个词不应高于 16 位随机串。
4. 打开开发者工具 Network，勾选「保留日志」，再点一次生成。文档请求和分析上报里不应出现刚显示在页面上的那串密码。随机源应来自 Web Crypto，而不是页面脚本里的 Math.random()——后者可在 Sources 里搜函数名核对。
5. 若还要对照公开弱口令名单，把准备淘汰的旧口令贴进本机检测，不要把新生成的主密码送去会上传原文的网站。未命中只说明它不在这份名单里，不能写成「从未拖库」。

MyPassGen 的密码生成器按这套边界工作：两种模式都用 getRandomValues 在当前标签页抽取；随机模式 6–128 位，默认 16，低于 8 位会提示较弱；可读模式 3–10 个词，词表 100 个，可加分隔符、数字、符号或首字母大写。一次最多 100 条，可复制或导出 TXT。打开即用，无账号、无密码库，关闭标签页后服务器上不会留下这些密码。你要核对的是 Network，不是口号。

从哪一步开始选

今天就要换的那一条，先回答能不能交给管理器。能，就生成 16 位或更长的随机字符，分别写入各站，不要复用。必须手输，就生成 8–10 个单词的可读密码，念给旁边的人时只念一次，不要再把同一条贴进群聊当备份。把秘密一次性交给远程同事时，走阅后即焚，密钥放在网址的 # 后面，而不是再复制一份明文。

路由器、Wi-Fi 和打印机属于典型手输场景：访客用手机键盘，符号和大小写混排容易敲错。这里用更长的单词串，比用 8 位「复杂」随机串更不容易被念错、抄错。管理后台若很少打开、且你自己带着管理器，仍应优先 16 位随机。

做完这一条分流，你就已经能回答本文的问题：随机还是可读，先看输入方式；四个单词够不够，先数词表有多大。100 词表上的四个词不够承担重要账户；默认 16 位随机串可以。页面给的档位，应当和这张表对得上，对不上就不要信「看起来像一句话所以更安全」。

常见问题

四个单词的可读密码能不能当主密码？

在 100 词表上不能。约 27 bits 只相当于一条偏短的随机串。主密码、磁盘加密口令这类很少更换、一旦泄露影响面大的秘密，应使用管理器保存的 16 位以上随机串，或把单词数加到 8–10 个，并确认随机源不是自己想出来的句子。

可读密码要不要再加大小写和符号，才能过网站的复杂度检查？

站点若仍强制混用字符类型，可以打开插入数字、符号或首字母大写，好让表单通过。这解决的是过时的拼写规则，不是熵的主要来源。NIST 已要求验证方不要再施加这类规则。过关之后，仍以单词数和词表为准。

生成随机密码或可读密码需要注册吗？结果会不会上传？

不需要注册。生成应留在当前标签页。把结果交给会上传原文的网站，才有日志风险。打开 Network：生成动作之后，请求体和分析事件里不应出现那串密码。需要留下副本时，复制或导出到你自己信任的位置；站内没有密码库。

手输的 Wi-Fi 口令，用随机 16 位还是单词口令？

看谁在输入。只有你会用管理器连接，用随机 16 位。经常有访客对着手机键盘敲，用 8–10 个单词，避免 0/O、1/l 和一串符号。不要把同一条 Wi-Fi 口令再用到路由器管理后台。