為什麼讀者會尋找密碼強度檢查器 API 替代方案
這個搜尋查詢在尋找密碼強度檢查器的 API 替代方案——意思是一種無需呼叫遠端 REST 端點、第三方服務或託管評分函式庫，就能評估密碼品質的方法。基於瀏覽器的本機稽核就是最直接的答案：把你打算使用的密碼貼上或輸入到一個完全在你裝置上運行的頁面，根據已公開的長度區間、字元群組與明顯模式，獲得透明且符合 NIST 標準的回饋，然後關閉分頁，整個過程不會有任何資料被上傳、儲存或記錄。與仍然需要你透過 HTTPS 把密碼傳送到另一台伺服器的 API 替代方案不同，本機檢查器從未讓密碼離開你的機器。它會計算 Unicode 字碼點、套用已公開的長度區間，並標記簡單的重複片段或單調序列——這些都是文件化的規則，而不是對熵的猜測。最終結果是幫助你挑選更好的密碼的回饋，而不是認證。本頁先說明用在本機瀏覽器執行的方案取代託管式密碼強度 API 時，該注意哪些事項，接著透過 密碼強度檢查器 逐步示範完整流程。
第一個動機是網路往返。呼叫託管式 API 代表你打算使用的密碼——或其雜湊值，視廠商而定——會透過 HTTPS 傳送到並非由你掌控的基礎架構。廠商的隱私權政策、金鑰處理方式、保留設定與過往外洩紀錄，都會成為你安全防線的一部分。本機稽核則完全消除這整個攻擊面：候選密碼唯一存在的地方，就是你螢幕上那個瀏覽器分頁。
第二個動機是延遲與速率限制。自架或瀏覽器端的強度計能在下個畫面更新前就給出判定。遠端 API 則會額外增加數十到數百毫秒的延遲，可能會被限速或按次計費，也可能在服務中斷時離線。對在表單輸入時驗證密碼的開發者，或強制執行政策 CI 工作流程來說，這些成本會快速累積。
第三個動機是評分方式的誠實。許多密碼強度 API 會以位元數的熵，或以年份計算的破解時間來宣傳。這些數字來自一些假設——字元集大小、攻擊者每秒猜測次數、攻擊者是否能取得你確切的模型——而這些假設在實務上幾乎從不成立。NIST SP 800-63B 的現行指引就明確指出，要為使用者自選的密碼估算熵是很困難的。透明的本機稽核會揭露它實際檢查了什麼，並拒絕捏造無法辯護的數字。
從 API 轉換為本機稽核時，改變了什麼
從密碼強度 API 切換到基於瀏覽器的檢查器，並不是一對一的替換。輸入、輸出、信任邊界與失敗情境全都會改變。下表摘要了在託管端點與本機密碼強度檢查器之間做選擇時，開發者或終端使用者應該考量的差異。
| 面向 | 託管式密碼強度 API | 本機瀏覽器稽核 |
|---|---|---|
| 密碼的處理位置 | 在你無法掌控的遠端伺服器上 | 僅存在於你裝置上的瀏覽器分頁中 |
| 評分是否需要網路 | 是——每次呼叫都需要連線 | 否——頁面載入後可離線運作 |
| 外洩資料庫比對 | 通常會比對廠商維護的清單 | 不執行；交由帳號提供者處理 |
| 帳號、金鑰或計費 | 通常為必要 | 無 |
| 輸出格式 | 包含分數、標籤，有時含熵位元數的 JSON | 長度、字元群組數、模式旗標、標籤 |
| 離線時的失敗情境 | 無法取得分數 | 分數仍可正常運作 |
| 信任邊界 | 廠商的隱私權政策與金鑰處理方式 | 你眼前的瀏覽器分頁 |
最關鍵的區別在於信任邊界。託管式 API 承擔了正確處理密碼的責任；本機稽核則把這份責任交還給你。兩者並沒有絕對的好壞——能比對最新外洩資料庫的伺服器，可以抓到瀏覽器無法察覺的已洩露密碼——但它們解決的是不同問題，也獎勵不同的使用習慣。最終選擇取決於：廠商外洩資料庫帶來的額外準確度，是否值得把候選密碼送上網路所增加的攻擊面。
在本機稽核候選密碼
以下的步驟以密碼強度檢查器作為具體的密碼強度檢查器 API 替代方案。每個動作都在瀏覽器內執行，不會上傳任何資料，除非你明確按下「顯示」，否則輸入內容會保持隱藏。
- 在瀏覽器中開啟密碼強度檢查器頁面。不需要登入、API 金鑰或帳號設定。
- 輸入或貼上你想評估的密碼。輸入欄位預設會遮罩內容，降低被旁人窺視的風險。
- 在檢視判定結果時保持輸入欄位隱藏——讀取分數或建議時不需要顯示密碼。
- 閱讀長度、描述性的字元群組數、模式旗標，以及頁面在輸入欄旁印出的每一項建議。
- 如果你需要確認輸入的內容——例如要除錯複製貼上的錯誤——可以按下「顯示」暫時顯示內容，之後再按下「隱藏」。
- 根據標籤、模式旗標以及頁面印出的建議，決定保留、重新產生或延長候選密碼。
- 使用 密碼產生器 或一段獨特冗長的 passphrase 產生最終密碼，將其存入密碼管理工具，然後提交給實際的服務。
- 儲存完成後，檢查該服務自帶的外洩或封鎖清單警告——即使本機強度計給出「Strong」分數也不例外——並為該帳號啟用 MFA。
整個流程會在對目的地服務發出第一次網路往返之前就結束，候選密碼從未離開這台裝置。
解讀五級評分
檢查器會根據固定的長度區間，從五個標籤中指派一個——Weak、Fair、Good、Strong，或是空字串時的零分。這些區間是回饋規則，並不是聲稱任何長字串就一定安全。這些區間與模式化字串的分數上限都已文件化，讓你能為每個判定辯護。
| 長度或條件 | 標籤（非模式化時） |
|---|---|
| 空字串 | 零分 |
| 少於 8 個字碼點 | Weak |
| 8 到 14 個字碼點 | Fair |
| 15 到 19 個字碼點，非模式化 | Good |
| 20 個以上字碼點，非模式化 | Strong |
| 任何長度但帶有被標記的模式 | 上限為 Fair |
長度是最主要的訊號，因為現行 NIST 指引認為，若密碼是唯一的認證因素，少於 15 個字元的密碼就視為偏弱。強度計計算的是 Unicode 字碼點而非 UTF-16 單位，因此一個表情符號會算成一個字碼點，而不是被默默拆成代理對。空格與非 ASCII 字元都有支援——它們能組成好記的 passphrase——前提是目標服務能一致地接受並正規化它們。字元群組數僅作為描述用途。頁面會回報你的字串是否包含小寫字母、大寫字母、數字、符號、空白字元或非 ASCII 字碼點；它不會要求任何特定組合。OWASP 的身分驗證速查表 建議不要強制組合規則，因為這會讓使用者傾向於可預測的替換，例如 Password1!，而非更強的密碼。
檢查器不會檢查的部分
本機稽核刻意只涵蓋很有限的範圍。模式偵測只尋找兩種特定形狀——一段最多四個字碼點的短片段重複三次以上，或是四個字碼點依序遞增或遞減一。這足以抓到像 aaaaaa、abcd 或 1234 這類情況，但僅此而已。它不會偵測像 qwerty 這種鍵盤連續輸入、引用的歌詞、人名、日期、語言字典單字，或外洩資料庫中出現的值。
「無模式」的判定僅代表這兩項檢查沒有觸發，並不代表這個密碼是獨特、不可猜測或未被重複使用。真實的攻擊者會使用外洩資料庫、字典、針對特定服務的詞彙、鍵盤路徑、個人事實與機率模型——他們並不會列舉所有可能的字元組合。本機強度計無法對應這些技術，假裝它能做到只會誤導你。八個鎖定的測試案例驗證了各項邊界；這個頁面刻意避免宣稱任何破解時間或熵位元數的保證。
檢查器同樣不會發出任何網路請求。它不會下載封鎖清單資料庫、不會把局部雜湊傳送給第三方外洩服務，也不會詢問帳號提供者。遵循帳號提供者自己的外洩警告，其優先順序高於任何本機標籤，包含 Strong。請把這個結果視為挑選更好密碼的指引，而非認證。
Building habits that go beyond any single meter
Treat the local score as guidance for choosing a better secret, not certification. The pattern is simple to follow once you internalize it.
- Generate a different random password for every account, store each one in a password manager, and never reuse secrets across services.
- Prefer a long unique passphrase — four or five unrelated words plus a few separators — or a manager-generated random string of 20 or more characters.
- Verify that the target service accepts the characters you plan to use, including spaces or accented letters, before you commit a passphrase to it.
- Check the complete value against the service's own blocklist when one exists, even when the local meter says Strong.
- Enable multi-factor authentication — ideally a phishing-resistant passkey or hardware token — for email, finance, cloud, and administrator access.
- Change a password only when it is reused, exposed, or suspected compromised; arbitrary calendar rotation is discouraged by current guidance.
- Audit the local rules against the official NIST SP 800-63B guidance and the OWASP Authentication Cheat Sheet whenever you tune policy.
If you want to dig deeper into how the rules produce the score — for example to port a similar check into JavaScript or to write a CI lint against these bands — the guide on the password strength algorithm and the rules behind the score walks through the same length bands and pattern thresholds the meter applies. If your goal is to make sure the secret never leaves the device during testing, the page on how to test password strength without uploading it lays out the local-only workflow in more detail.
For developers, operators, and end users alike, the right password strength checker API alternative is the one whose limits you understand. A transparent local meter that discloses what it counts, what it flags, and what it cannot see pairs cleanly with the things only the account provider can do — a current breach-corpus lookup, MFA enforcement, and salted password hashing on the server side. Score locally, verify at the service, and protect the account with a second factor.