密碼與權杖產生器
密碼、口令短語與 API 權杖，全部由瀏覽器的加密隨機源產生——crypto.getRandomValues，從不是 Math.random——並且只存在於這個分頁裡。密碼最不該產生的地方，就是有紀錄的 AI 對話：那裡的「隨機」字串是預測出來的文字，而對話還留著一份副本。在這裡，隨機是真的，副本只屬於你。
密碼
口令短語
API 權杖
強度檢查器
隨機是一種機制，不是感覺
本頁面的每個秘密都來自 crypto.getRandomValues，瀏覽器對作業系統熵池的介面——你的密碼管理器用的也是同一個來源。選擇採用拒絕抽樣，所以每個字元、每個單詞都等機率；對隨機位元組天真地取模會悄悄偏袒某些字元，而在密碼產生器裡，悄悄的偏差是真缺陷。Math.random 在這裡完全不出現：它是為動畫造的快速、可預測的產生器，未來的輸出可以從過去的輸出重建。每個結果旁列印的熵值由真實的池計算——四組字元的 20 字元密碼是 20 × log₂(95) ≈ 131 位元；560 詞表裡的五詞口令是 5 × log₂(560) ≈ 45 位元——所以你能按真實強度、而不是按看起來多複雜來比較形態。驅動整頁的那條操作規則值得重申：在對話視窗裡產生的密碼，就是被存進那次對話歷史的密碼，存在別人的基礎設施上、一個可能被攻破的帳戶之下。主打文章 不要讓聊天機器人碰你的金鑰 給出完整論證；雜湊識別器 則是將來某天你以摘要形態遇見自己舊密碼時的伴侶工具。注意：口令短語的詞表保持英文（那是短語的資料本身）。
常見問題
為什麼不直接讓聊天機器人給個密碼？
三個理由，各自都足夠。聊天機器人的「隨機」密碼是預測文字，不是抽樣出的隨機——模型有可測量的偏好模式，而一個攻擊者能預測其形態的密碼等於被猜中了一半。聊天是紀錄在案的：剛剛遞給你的密碼存在於第三方伺服器上的對話歷史裡，與你的帳戶綁定。而且模型無法使用真正的隨機源——聊天補全的背後沒有 crypto.getRandomValues。本產生器直接抽樣瀏覽器的加密隨機源，結果只存在於這個分頁。完整論證在 不要讓聊天機器人碰你的金鑰。
密碼還是口令短語——該用哪個？
兩個都用，給不同的手。機器儲存的憑證（密碼管理器的條目、API 權杖）應該是密碼或權杖：每字元熵最大，從不由人輸入。任何必須由人輸入或記憶的東西——首要的是密碼管理器自身的主密碼——應該是口令短語：560 詞表裡的五個詞約有 45 位元，並且真能記住；而它替代的「聰明」10 字元密碼通常攜帶更少，還會被忘在星期五。
熵值這個數字到底是什麼意思？
攻擊者要暴力破解這個秘密，平均需要回答的是非題數量的一半，即 2^位元 次的一半——前提是他們確切知道它是如何產生的，誠實的估算總是這樣假設。40 位元會敗給有租 GPU 決心的攻擊者；65 位元對批量攻擊已在實際可達之外；100 位元以上則徹底不可達，除非攻破數學本身。產生器的數字對自己的輸出是精確的，因為池和長度已知；強度檢查器的數字標為估算，因為輸入密碼的真實池只能靠猜。
強度檢查器的判定可信嗎？
可信作下限，不可信作承諾。它建模你的字元隱含的池，然後對破解字典最先利用的模式收費——重複、字母與鍵盤序列、年份，以及網際網路最常見的密碼本身。它看不見的是含義：寵物名加生日在數學上是「尚可」，對認識你的人卻毫無價值。把好判定當作必要條件，而非充分條件——只要機器能儲存，就優先用產生的秘密，而不是評級的秘密。
產生的密碼會被儲存或傳送到哪裡嗎？
不會。產生在本頁面中由 crypto.getRandomValues 完成，結果活在分頁的記憶體裡，直到你關閉它。沒有帳戶、沒有同步、沒有攜帶你輸出的分析事件。但推論在你這邊：產生的密碼若不立即存進密碼管理器，分頁一關就沒了——這是正確的失敗模式，但要有所計畫。