客服把公司 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 個單字。下面的數字你可以自己用計算機覆核。
先做一次分流
這組密碼以後會不會由管理器自動填入？會，就走隨機字元，長度用預設 16 碼或更長。必須對著螢幕手打——訪客連 Wi-Fi、印表機分享、偶爾登入的路由器——再改用可讀密碼，並把單字數加到 8 個以上，而不是停在四個。
先問能不能交給管理器
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 個詞，等於五枚六面骰子的組合數 65。每詞約 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 以下為強，以上為極強。這是給自己看的尺標，不是對某張顯示卡的承諾。
| 做法 | 大約熵 | 按內部等級 |
|---|---|---|
| 100 詞 × 4 個單字 | 約 27 bits | 弱 |
| 100 詞 × 6 個單字 | 約 40 bits | 中（剛過線） |
| 100 詞 × 8 個單字 | 約 53 bits | 中 |
| 100 詞 × 10 個單字 | 約 66 bits | 強 |
| Diceware 7,776 詞 × 4 個單字 | 約 52 bits | 中 |
| Diceware 7,776 詞 × 6 個單字 | 約 77.5 bits | 強（EFF 建議的量級） |
| 隨機 8 碼（80 字元池） | 約 51 bits | 中 |
| 隨機 16 碼（80 字元池） | 約 101 bits | 極強 |
讀表時只抓兩件事。第一，預設 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 裡的請求列和請求主體，而不是看鎖頭圖示。
不要把剛產生的密碼再貼進會上傳原文的「強度網站」
有的檢測頁會把密碼原文 POST 出去，有的只送雜湊前綴。本機檢測只下載公開弱密碼名單，待測密碼留在輸入框。差別見本機對照外洩名單，和全網密碼查詢差在哪。產生和檢測都可以開啟即用，無需註冊。
當場核對
下面這組步驟不依賴品牌承諾。用一組不會用於真實帳號的密碼做試驗即可。
- 打開產生頁，選可讀密碼，單字數設為 4，產生一組。記下頁面給出的強度等級和熵。按上表，100 詞 × 4 應落在弱（約 27 bits）附近。
- 把單字數改成 8 或 10，再產生。等級應上升；10 個詞應接近「強」。不要改用自己想的四個詞來「優化」結果。
- 切到隨機字元，長度保持預設 16，四類字元都打開，再產生。等級應為極強（約 101 bits）。把三組結果並排看：可讀四個詞不應高於 16 碼隨機字串。
- 打開開發者工具 Network，勾選「保留紀錄」，再點一次產生。文件請求和分析回傳裡不應出現剛顯示在頁面上的那串密碼。隨機來源應來自 Web Crypto，而不是頁面腳本裡的
Math.random()——後者可在 Sources 裡搜函式名稱核對。 - 若還要對照公開弱密碼名單，把準備淘汰的舊密碼貼進本機檢測，不要把新產生的主密碼送去會上傳原文的網站。沒命中只說明它不在這份名單裡，不能寫成「從未被拖庫」。
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 密碼再用到路由器管理後台。