密碼安全完全指南：如何生成與管理真正可靠的強密碼
你的密碼，可能比你想的更脆弱
幾乎每個月都有大網站洩露用戶資料的消息。洩露之後，最危險的不是「我的密碼被看到了」，而是大多數人一套密碼走天下——A 站洩露的帳號密碼，攻擊者拿去撞 B 站、C 站，十之八九能直接登進去。
還有一類人走另一個極端：把 P@ssw0rd1! 當成「夠複雜了」。這其實是自欺欺人。我們在做工具庫的密碼工具這幾年反覆強調一件事：密碼的強度不是你「覺得」多複雜，而是它實際有多難被算出來。
根據 Have I Been Pwned 等洩露庫統計，常年出現在撞庫字典裡的弱密碼就那麼幾百個變體。password、123456、qwerty、P@ssw0rd 這些，佔了真實洩露量的驚人比例。你以為的「創意」，在攻擊者眼裡早就是公開劇本。
攻擊者是怎麼破你密碼的
- 撞庫（Credential Stuffing）：從別處買來/拖庫的帳號密碼，自動批次去各網站試登入。這是「一套密碼通用」最致命的原因——你一個帳戶洩露，所有帳戶跟著裸奔。
- 暴力破解 / 字典攻擊：短密碼、常見單字組合，在普通顯卡上幾秒到幾分鐘就能窮舉完。一張消費級顯卡每秒能試幾十億次雜湊。
- 社會工程與個人資訊：生日、名字、寵物、車牌。攻擊者只要稍微了解你（或你的社群帳號），就能把這些塞進字典優先試。
- 彩虹表（Rainbow Table）：提前算好「常見密碼 → 雜湊」的對照表，拿到洩露的雜湊庫直接反查。加鹽（salt）能廢掉它。
注意這幾類的共同前提：你的密碼要么太常見，要么太短，要么和你的資訊有關。只要避開這三點，破解成本就會高到沒人願意碰你。
什麼才是真正的「強」
三個標準，按重要性排序：
- 夠長：12–16 個字元起步。長度對破解成本的提升是指數級的，比任何「加個符號」都管用。一個 12 位隨機密碼，比 8 位複雜密碼難破幾個數量級。
- 真隨機：字元來自密碼學亂數產生器，不是你腦子裡編的。人編的密碼有明顯的模式（比如首字母大寫、結尾加數字），熵很低。
- 唯一：每個站點不同。這一條單獨就能擋住撞庫。
不同密碼被破解的時間量級（基於離線暴力，僅作直覺參考；實際取決於攻擊者算力）：
| 密碼 | 大約破解成本 |
|---|---|
password123 |
瞬間 |
P@ssw0rd1! |
字典攻擊下幾秒 |
| 8 位隨機字母數字 | 數小時到數天 |
| 12 位隨機字母數字符號 | 數千年以上 |
| 4 個隨機字組成的口號密碼 | 也上千年 |
熵：給「強度」一個可量化的標準
密碼學裡用「熵（entropy，單位 bit）」衡量隨機性。粗略公式：熵 ≈ 字元集大小對數 × 長度。
- 小寫字母（26 種）：每個字元約貢獻 log₂26 ≈ 4.7 bit
- 加數字（36 種）：約 5.17 bit
- 大小寫+數字+符號（約 95 種）：約 6.57 bit
所以：
| 密碼 | 估算熵 |
|---|---|
| 8 位複雜字元 | ~52 bit |
| 12 位複雜字元 | ~79 bit |
| 4 個隨機常用字（每字~11bit） | ~44–55 bit |
| 5 個隨機常用字 | ~55–65 bit |
經驗閾值：熵 ≥ 60 bit 算「強」，≥ 80 bit 算「很強」。這就是為什麼口號密碼只要字夠多、真隨機，就能和亂碼一樣扛揍。
怎麼生成：交給工具，別靠腦子
自己想密碼，再「隨機」也帶著習慣。讓工具用密碼學亂數生成才靠譜：
- 隨機密碼 / Token 產生器：可配置長度和字元集（大小寫、數字、符號），底層用
crypto亂數，不是偽隨機。 - 生成完順手用密碼強度分析掃一眼，確認沒有被常見規則誤判為弱。
長度建議直接拉到 16 位以上。多一位，破解成本翻幾十倍。下面是正確和錯誤的生成方式對比：
// ❌ 錯誤：Math.random 是偽隨機，可被預測，別用於密碼
const weak = Math.random().toString(36).slice(2, 10);
// ✅ 正確：用 Web Crypto 的密碼學亂數
function genPassword(len = 16) {
const chars = 'ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789';
const arr = new Uint32Array(len);
crypto.getRandomValues(arr);
return Array.from(arr, n => chars[n % chars.length]).join('');
}
口號密碼：又好記，又扛揍
如果嫌亂碼難記，試試口號密碼（Passphrase）——Diceware 思路：挑 4–5 個互不相關的隨機字，用分隔符連起來，比如 correct-horse-battery-staple（經典範例）。
它比同等長度的亂碼更好記，熵卻一點不低：每個常用字約貢獻 10–13 bit 熵，5 個字就是 50–65 bit，遠超大多數隨機短密碼。對手寫腦記型使用者，這是最實用的方案。
別用名言、歌詞、或者「把一句話首字連起來」——那依然是可預測的模式。字必須真的是隨機選的（用工具的隨機字功能，別自己挑）。
進階：在字之間加隨機數字和符號，比如 correct-7-horse-battery-3-staple，熵再上一個台階，也不難記。
管理：管理器 + 唯一 + 雙因素
生成強密碼只是第一步，記不住就白搭。
- 用密碼管理器（Bitwarden、1Password、KeePass 等）：每個站點存一個唯一強密碼，你只守住一個主密碼。主密碼建議用上面的口號密碼思路。好的管理器是零知識架構——你的庫在本地加密，服務商也看不到明文。
- 開雙因素（2FA）：就算密碼洩露，多一道動態碼也登不進。TOTP 工具可以產生步步驗證碼，比簡訊可靠。
- 重要帳戶別只靠簡訊驗證：SIM 互換攻擊能劫持簡訊，能上 TOTP 或硬體金鑰（如通行金鑰/Passkey）的優先上。
雙因素方式的可靠度排序：
| 方式 | 安全度 | 備註 |
|---|---|---|
| 硬體金鑰 / Passkey（WebAuthn） | 最高 | 防釣魚，無密可偷 |
| TOTP 驗證器 App | 高 | 不依賴簡訊，推薦 |
| 簡訊 SMS | 低 | 可被 SIM 互換劫持 |
| 郵件驗證碼 | 中低 | 郵箱若洩露則連帶失效 |
開發者視角：秘密怎麼存
如果你是寫後端的，一條鐵律：永遠不要明文存密碼。
雜湊，而不是加密
密碼應該只存雜湊——用 bcrypt / Argon2 / PBKDF2，並且加鹽。注意：「雜湊」和「加密」不同：加密可逆，雜湊不可逆。你不需要（也不應該）能還原用戶密碼。
工具庫提供了雜湊工具（MD5/SHA 等摘要）和bcrypt 工具（專門做密碼雜湊）。重要：MD5/SHA 是通用摘要演算法，算得太快，不適合直接存密碼——它們擋不住暴力破解。正式儲存請用 bcrypt / Argon2 / scrypt 這類「慢雜湊」。
// Node.js：用 bcrypt 存密碼（正確姿勢）
import bcrypt from 'bcrypt';
const saltRounds = 12; // 越大越慢越安全，12 是常見值
const hash = await bcrypt.hash(password, saltRounds);
// 存 hash 進資料庫，別存 password
// 登入時校驗
const ok = await bcrypt.compare(inputPassword, hashFromDb);
// Node.js：用 Argon2（更現代，推薦新專案）
import argon2 from 'argon2';
const hash = await argon2.hash(password, {
type: argon2.argon2id,
memoryCost: 65536, // 64 MB
timeCost: 3,
parallelism: 1,
});
鹽（salt）、胡椒（pepper）與防爆破
- 鹽：每個用戶隨機一串，混進雜湊，存進資料庫。作用是讓相同密碼產生不同雜湊，廢掉彩虹表和撞庫。bcrypt/Argon2 會自動加鹽，直接用即可。
- 胡椒（pepper）：全域一個金鑰，不進資料庫（放環境變數/金鑰管理），在雜湊前先拼到密碼上。即使資料庫洩露，沒有 pepper 也難破解。
- 限速與鎖死：登入介面必須限流、失敗次數鎖定、加驗證碼，擋住線上暴力。
- 時序攻擊：用「恆定時間比較」校驗雜湊（bcrypt.compare 內部已做），別用
==直接比。
需要可逆時再用加密
比如要回推的金鑰、用戶授權的第三方 token，用AES-256-GCM 工具，口令經 PBKDF2 派生金鑰，全程本地。但「用戶登入密碼」永遠不該可逆——那是設計錯誤。
永遠別把用戶密碼寫進日誌、別存明文資料庫、別在前端做「密碼強度」之外的任何處理。前端強度提示只是 UX，真正的安全在後端雜湊。
合規參考：NIST 的新思路
美國 NIST 800-63B 早就推翻了「每 30 天強制換密碼」「必須包含大小寫+數字+符號」的老套路。新建議：
- 長度優先（至少 8，建議更長），而非強制複雜組合；
- 不要強制定期更換（沒洩露就別換，強制定期換反而催生弱密碼）；
- 檢查密碼是否在已知洩露庫中（用 k-anonymity 介面查前綴，不洩露完整密碼）；
- 允許貼上密碼（方便用管理器）；
- 限制最大長度即可，別限制特殊字元。
密碼強度分析工具的實作思路就參考了這些原則——不只看「有沒有符號」，更看長度和是否落入常見模式。
常見錯誤
| 錯誤 | 後果 | 正確做法 |
|---|---|---|
| 一套密碼通用 | 一處洩露全崩 | 每站唯一 |
P@ssw0rd 式替換 |
字典秒破 | 真隨機 / 口號密碼 |
| 寫在手機備忘錄 | 手機丟就完 | 密碼管理器 |
| 只開簡訊 2FA | SIM 互換可劫持 | TOTP / 硬體金鑰 |
| 用短 PIN 當密碼 | 暴力秒破 | 12–16+ 字元 |
| 後端明文存密碼 | 一洩露全曝光 | bcrypt / Argon2 雜湊 |
| 用 MD5/SHA 直接存密碼 | 快雜湊擋不住爆破 | 用慢雜湊演算法 |
常見問題
密碼要定期換嗎？ 沒有洩露跡象就不用（遵循 NIST 新指南）。強制每 30 天換一次，反而讓人寫下弱密碼或只改末尾數字。等出現洩露再換。
口號密碼和亂碼密碼哪個好？ 都行，關鍵是長度和隨機性。口號密碼勝在好記，適合主密碼和手寫記錄；隨機亂碼適合管理器自動填的站點密碼。
發現某站洩露了怎麼辦？ 立刻改掉那個站（以及所有重用同一密碼的站）的密碼 → 開 2FA → 去 Have I Been Pwned 查自己哪些郵箱中招。
密碼管理器的主密碼忘了會怎樣？ 主密碼通常無找回機制（這是它安全的代價）。所以主密碼一定要用你真正記得住、又夠長的口號密碼，並留一份離線備份（手寫鎖進抽屜）。
開發者：用哪個雜湊演算法？ 新專案優先 Argon2id；要相容老系統用 bcrypt（cost≥12）。避免直接用 MD5/SHA 存密碼。
帳號安全自檢清單
1. 有沒有重複使用的密碼？ → 用 /encode/password 生成唯一強密碼逐個替換
2. 長度夠嗎（≥12，建議 16+）？ 不夠就加長
3. 開了雙因素嗎？ → 優先 TOTP（/utils/totp）或 Passkey，別只靠簡訊
4. 開發者：密碼是雜湊儲存嗎？ → /encode/bcrypt，別明文，別用 MD5/SHA
5. 主密碼好記又夠強嗎？ → 用口號密碼思路，留離線備份
6. 有沒有在洩露庫裡？ → 定期查 Have I Been Pwned
把這六條過一遍，你的帳號安全等級會比絕大多數人高出一個身位。密碼這件事，早一天認真，少一天提心吊膽。相關的圖片/文件隱私處理，可以參考資料隱私指南。
本站提供瀏覽器本地工具，免註冊即可試用 →