密碼強度演算法是指檢查工具為了產生分數或標籤而套用於候選密碼的一套規則。密碼強度檢查工具的演算法會計算 Unicode 碼位數、回報出現了幾個廣義的字元群組、標記簡單的重複或連續模式，並指派一個從「弱」到「強」的五級標籤。由於目前的 NIST 指引把僅作為唯一身分驗證因素、長度短於 15 個字元的密碼視為弱密碼，因此這個演算法把長度列為優先，並採用模式上限，而不是宣稱破解時間或熵位元數的保證。空輸入得零分;少於 8 個字元為「弱」;8 到 14 個字元為「中等」，除非偵測到簡單的重複或連續模式;未觸發模式的 15 到 19 個字元為「良好」，而 20 個字元以上為「強」。這些分級是回饋規則，並非聲稱每個長字串都是安全的;這個計分器不會發出任何網路請求、不儲存任何資料，也拒絕為使用者自選的字串估計熵值。
密碼強度演算法量測的是什麼
一套值得信賴的密碼強度演算法，運作基礎是使用者可以審核的一小組輸入。密碼強度檢查工具恰好從候選密碼取出三個可觀察的輸入，並產生一個確定性的結果，任何人只要拿到同一個字串與同一套規則，就能重現這個結果。
- Unicode 碼位長度。每一個字元 — 包括表情符號、空格、腔調字以及其他非 ASCII 碼位 — 都算作一個。這個演算法不會切分輔助平面字元，也不會套用 UTF-16 運算，因此像 🎉 這種表情符號只貢獻一個碼位，而非兩個代理項。
- 字元群組存在性。這個演算法會回報出現了幾個廣義群組:小寫字母、大寫字母、數字、符號、空白字元，以及非 ASCII 字元。群組數量僅供描述，演算法從不要求必須出現特定群組。
- 模式比對。兩項範圍明確、可解釋的檢查會在下列情況觸發:演算法發現一段長度最多 4 個碼位的短片段重複出現至少 3 次，或是一段 4 個碼位的字串以逐一遞增或遞減的方式連續排列。
從這三項輸入出發，演算法得出五級標籤。沒有熵估計、沒有破解時間標題、沒有遠端查詢;這正是重點所在:結果是可審核的，而不是做表面工夫。
五級分數如何計算
評分規則刻意設計得平淡無奇，才能被推敲。因為 NIST SP 800-63B 把僅作為唯一身分驗證因素的短密碼視為弱密碼，所以長度成為主導因素;而簡單的模式上限則避免已知的陷阱拿到被灌水的標籤。
| 標籤 | 條件 |
|---|---|
| 空 | 未輸入任何字元(分數 0) |
| 弱 | 少於 8 個字元 |
| 中等 | 8 到 14 個字元，或任何會觸發簡單重複或連續模式的長度 |
| 良好 | 15 到 19 個字元，未觸發模式 |
| 強 | 20 個字元以上，未觸發模式 |
模式上限很重要:一組 30 個字元、由 abcabcabcabc 構成的字串仍然評為「中等」，因為重複片段規則會先觸發。同樣地，1234abcd 會被降級，因為演算法偵測到一段 4 個字元的單調序列。共有 8 組測試密碼把這些界線鎖定在測試之中，讓公布的標籤不會飄移:空、短、連續、重複、一組 14 個字元的值、一組 11 個字元的混合值、一組 19 個字元的詞組，以及一組 28 個字元的密語。
這個演算法不要求每個字元群組都出現，也不會因為強迫組成的複雜度而給予加分。強迫加入大寫、數字與符號，往往會把使用者推向可預測的替換，例如 P@ssw0rd1;而這正是強迫組成規則容易助長的可預測替換類型。空格與 Unicode 是被允許的，因此一段好記的密語可以依其本身條件被評估，只要目標服務能接受並一致地正規化這些字元。
模式偵測:規則涵蓋的範圍
模式偵測刻意設計得很狹隘，讓演算法能解釋每一項發現。重複片段規則會尋找一段長度 1 到 4 個碼位、在輸入中連續或散布出現至少 3 次的子字串。連續規則則尋找 4 個以嚴格遞增或遞減排列的碼位，例如 abcd、4321 或 wxyz。無論是哪一條規則觸發，演算法都會把分數上限壓在「中等」，不論長度為何。
演算法沒有涵蓋的部分同樣值得記錄。它不會辨識:
- 超過 4 個碼位的鍵盤走勢，例如跨欄的 1qaz2wsx。
- 字典單字、姓名、日期、歌詞或純粹剛好很長的引言。
- 已外洩的密碼，或出現在公開外洩語料庫中的值。
- 服務特有的詞彙，或攻擊者可能從社交脈絡推測出的個人事實。
一個乾淨的「無模式」旗標，僅代表那兩項狹隘的檢查沒有觸發。演算法對這條界線坦誠以對:「強」標籤涵蓋的是有文件依據的本地長度與簡單模式檢查，除此之外什麼都沒有。
三步驟對密碼執行演算法
- 開啟 密碼強度檢查工具，把候選密碼輸入或貼到輸入欄位。預設會隱藏內容，任何資料都不會離開你的瀏覽器;只有在你需要看到輸入內容時，才按下 顯示。
- 檢視演算法輸出的四項結果:Unicode 碼位長度、字元群組的描述性計數、模式旗標(重複、連續或無模式)，以及每一條建議。每一條寫在分數旁的建議都會指出觸發的規則名稱。
- 把結果與演算法不會檢查的三件事進行對照:是否出現在最新的外洩或封鎖清單中、相較於你其他密碼是否唯一，以及是否啟用多重要素驗證。請使用密碼管理工具為每個帳號產生並儲存不同的值;若服務支援，優先選擇可抗釣魚的 passkey。若想搭配這篇演算法說明深入閱讀方法論，可參考這份以正確方式判斷密碼強度的指南，內容涵蓋相關的決策依據。
演算法無法偵測的部分
為使用者自選的密碼估計熵，確實非常困難;這也是 NIST SP 800-63B 建議不要為人為輸入宣稱熵位元數的原因。密碼強度檢查工具刻意拒絕這類主張。攻擊者不會逐一嘗試所有組合;他們使用的是外洩語料庫、字典、服務專屬的單字清單、鍵盤路徑、個人事實，以及機率模型 — 這些都不是一個只憑長度的計分器能在本地端建模的。
演算法同樣無法驗證這組密碼是否專屬於這個帳號。一段 28 個字元的密語若重複用於三個服務，仍然是單一故障點，而計分器無從得知。OWASP 身分驗證速查表 建議在伺服器端使用 Argon2id、bcrypt 或 scrypt 等含鹽的密碼雜湊函式;這正是伺服器端常見、預期且已遭破解之值的封鎖清單之所以適合用來攔截外洩祕密的原因。請把本地端分數視為挑選更好祕密的參考，而不是認證。
超越分數:密碼管理工具、封鎖清單、多重要素驗證
演算法只是密碼完整決策中的一項輸入。其餘的輸入屬於作業層面，而且比標籤本身更為重要。
- 使用密碼管理工具。為每個帳號產生一組不同的隨機密碼、儲存在管理工具中，並讓它代為填入欄位。唯一性正是中和跨站外洩重複使用的關鍵，而長度自然就由管理工具免費提供。
- 檢查服務的封鎖清單。本地計分器不會查詢外洩語料庫。請讓帳號服務商在註冊或變更密碼時執行比對，即使本地計分器顯示「強」，也要信任它的警告。
- 啟用多重要素驗證。至少為電子郵件、金融、雲端與管理員權限的存取加上第二因素。若支援，優先採用可抗釣魚的 passkey，因為它能把密碼從攻擊面中完全移除。
- 依證據輪換，而非依行事曆。只有在密碼被重複使用、外洩或疑似遭到破解時才變更。被強迫的定期輪換，往往會產生像 Spring2026! 後接 Summer2026! 這類可預測的變體;演算法會樂於把它標為「中等」，卻對實際安全毫無助益。
執行演算法、字面解讀四項輸出，再加上作業面的控管。這樣的組合 — 透明的本地規則加上管理工具、服務封鎖清單與第二因素 — 才是縮短標籤與實際防禦之間差距的方法。
若你正在權衡選項，免費的 16 字元本地端密碼產生器對此有詳細說明。