密碼應該怎麼儲存？Argon2id、bcrypt、Salt、Pepper 與密碼政策完整指南

先講結論：密碼只能驗證，不應被系統還原

登入時，系統真正需要回答的是『這次輸入是否與註冊時相同』，而不是取回原始密碼。因此密碼應經專用的單向 Password Hashing／Key Derivation Function 產生 Password Verifier；再次登入時，使用同一組演算法、Salt 與參數計算後，以安全比較函式驗證結果。

可逆加密適合日後必須取回明文的資料，不適合一般登入密碼。只要解密金鑰能被應用程式取得，攻擊者在拿到資料庫與金鑰後也能批次還原全部密碼。Base64、URL Encoding 或自製字元替換更只是編碼，沒有密碼學保護。

即使使用雜湊，安全也不是『Hash 無法逆推』這一句話。攻擊者不必逆運算，只要對常見密碼、字典、規則變形與外洩清單逐一計算並比對即可。設計重點是讓每次猜測成本夠高、不同帳號不能共用預先計算成果，並讓演算法與成本可以持續升級。

• 絕不保存、記錄、傳送或備份明文密碼
• 不使用 MD5、SHA-1、SHA-256、SHA-512 等快速雜湊直接儲存密碼
• 不自創雜湊串接、加密格式或 Salt 生成方式
• 使用成熟框架提供的 password_hash／verify API，而不是一般雜湊 API

先定義威脅模型：資料庫外洩、應用程式失陷與線上猜測不同

密碼雜湊主要防的是 Offline Guessing：攻擊者取得 User Table、Backup、Snapshot 或 Query Dump 後，在自己的 GPU／ASIC／雲端資源上無限次嘗試，不再受網站 Rate Limit 約束。Salt 讓每筆帳號必須分開計算；慢速與記憶體困難演算法提高單次猜測成本；Pepper 在資料庫單獨外洩時再增加一個攻擊者拿不到的秘密。

如果攻擊者已控制應用程式執行環境、CI/CD、Secret Manager 權限或登入程式，他可能同時取得 Pepper、攔截新輸入的密碼或呼叫合法驗證流程。此時單靠雜湊無法解決問題，還需要工作負載身分、最小權限、Secret 存取稽核、Runtime 防護、快速金鑰輪替與完整事件應變。

Credential Stuffing、Password Spraying 與線上 Brute Force 則發生在登入端點。再強的 Argon2id 也不會自動阻止攻擊者嘗試已外洩的正確密碼；必須另有 Blocklist、Rate Limit、裝置／行為風險、MFA、Passkey 與異常通知。

Hash、Encryption、Encoding 到底差在哪裡？

Password Hashing 是單向驗證：系統保存由 Password、Salt 與 Cost 產生的 Verifier，之後只比較，不需要取回原文。Encryption 是雙向機密性控制：有 Key 即可解密，適合地址、Token 或依法必須還原的資料。Encoding 只改變表示方式，任何人都能還原。

一般 SHA-256 雖然是密碼學雜湊，但它被設計得很快。對檔案完整性是優點，對低熵密碼卻是缺點，因為攻擊者能大量並行嘗試。Password Hashing Function 則刻意消耗時間、記憶體或兩者，並允許成本參數隨硬體進步調高。

為什麼新系統優先選 Argon2id？

Argon2 是 Password Hashing Competition 的得主，Argon2id 結合 Argon2i 與 Argon2d 的特性，在 Side-channel 防護與抵抗 GPU／專用硬體之間取平衡。它的核心不是單純『多跑幾次』，而是要求每次計算占用可設定的記憶體，讓攻擊者要高速平行破解時也必須付出大量 RAM 與記憶體頻寬成本。

Argon2id 有三個主要參數：m 是每次雜湊使用的記憶體、t 是 Pass／Iteration 次數、p 是 Parallelism。參數彼此有資源取捨，不能只看一個數字，也不能把個人電腦的測試直接套到所有 Pod、Function 或高流量登入服務。

OWASP 目前提供的最低基準之一是 m=19 MiB、t=2、p=1；RFC 9106 在記憶體受限環境的第二建議則是 64 MiB、t=3、p=4。兩者服務的部署假設不同：前者是務實下限，後者是 RFC 的均衡建議。正式參數應以自己的生產硬體、最大並行登入量與可接受延遲實測，並在資源允許時高於最低值。

Argon2id 參數不能照抄：用容量模型做基準測試

參數選擇要從風險與容量共同反推。先在與正式環境相同的 CPU、Memory Limit、Container Runtime 與 Library 版本上測量單次 Hash／Verify，再以尖峰登入併發、Autoscaling 延遲、Password Reset 批次與惡意請求情境做 Load Test。

例如每次使用 64 MiB，不代表一台有 8 GiB RAM 的服務可以安全承受 128 個同時驗證；還要扣除 Runtime、Cache、Sidecar 與其他 Request，並保留錯誤與擴縮容空間。若成本太高造成資源耗盡，攻擊者反而能用登入請求發動 Application-layer DoS。

應設定兩層限制：在 Edge／API 層按 Account、IP、Device 與風險節流，避免無限進入昂貴 KDF；在應用層限制同時 Hash Job 數並設定 Queue／Timeout。不要用降低到不安全參數作為唯一容量解法。

• 記錄單次 Verify 的 p50、p95、p99 延遲與實際峰值記憶體
• 測試正確密碼、錯誤密碼、不存在帳號與超長輸入是否走近似成本路徑
• 用尖峰而非平均登入量估算最大安全並行數
• 把演算法、Library、Runtime、CPU 型號與測試日期寫入決策紀錄
• 每年或硬體／架構變更後重新 Benchmark，逐步提高成本

Salt 是公開且每筆唯一的值，不是另一組密碼

Salt 的作用是讓兩個使用相同密碼的帳號產生不同 Verifier，也讓攻擊者不能用一張預先計算表同時破解整批資料。Salt 不需要保密，應和 Hash、演算法及成本參數一起保存。現代成熟 Password Hash Library 通常會自動使用 CSPRNG 產生並把 Salt 編入標準格式。

常見錯誤包括全站共用固定 Salt、用 Username／Timestamp 當 Salt、把 Salt 寫死在 Source Code，或誤以為把 Salt 藏起來就等於 Pepper。只要不具備每筆獨立、不可預測與足夠碰撞空間，Salt 的價值就會下降。

應優先使用 Library 的封裝格式與 Salt 生成，不要手動拼接字串。若系統必須自管，採用至少 128-bit 隨機 Salt 是常見且保守的工程選擇；NIST 的規範下限雖為 32 bits，並不代表新設計應只做最低下限。

Pepper 是資料庫之外的秘密控制，不能與 Salt 混用

Pepper 是所有帳號或一個受控範圍共用的 Secret，用於雜湊前的 keyed transform 或雜湊後的 HMAC。它的價值建立在『攻擊者只拿到資料庫，沒有取得 Pepper』；因此 Pepper 絕不能與 Hash 放在同一個 Table、Backup、Environment Dump 或可由相同資料庫權限讀取的位置。

Pepper 應由 Secret Manager、HSM 或受保護的執行環境保存，透過工作負載身分按需使用，並記錄存取。不要把它硬編碼在 Repository、Docker Image、前端 Bundle、一般環境變數範本或部署腳本。若應用程式能讀取明文 Pepper，其執行身分與 Runtime 仍是重要攻擊面。

Pepper 有一個必須預先設計的代價：在不知道使用者原始密碼時，無法直接替既有 Verifier 換 Pepper。若 Pepper 外洩，通常需要保留受控的舊版本驗證期間、在成功登入時升級，並對未回訪帳號強制 Reset；高風險事件則可能必須立即讓全部舊 Verifier 失效。

• Salt：每筆唯一、可公開、與 Hash 一起保存
• Pepper：跨筆共用或分群、必須保密、與資料庫分離
• 沒有 Pepper 仍可做安全雜湊；沒有唯一 Salt 則是基本設計缺陷
• Pepper 只是 Defense in Depth，不能把 SHA-256 變成合格的密碼儲存方案

bcrypt、scrypt、PBKDF2 什麼時候還能用？

bcrypt 已被廣泛部署，但 OWASP 將它定位為 Argon2id 或 scrypt 不可用時的 Legacy 選項，Work Factor 至少 10，且多數實作只處理前 72 bytes。最危險的情況不是使用者看到上限，而是系統靜默截斷：兩組後段不同的長密碼可能被當成相同輸入。

若既有 bcrypt 系統需要支援超過 72 bytes，不應隨意在前面加一層快速 Hash。OWASP 提醒錯誤的 Pre-hash 會遇到 Null Byte、Password Shucking 與編碼問題；應遵循經審查的 HMAC＋Pepper＋Base64 方案或直接規劃遷移 Argon2id，並用跨版本測試向量驗證。

scrypt 同樣是 Memory-hard KDF，可在 Argon2id 不可用時使用。PBKDF2 主要以大量 Iteration 提高 CPU 成本，不具同等記憶體成本；但在 FIPS-140 驗證實作是必要條件時，PBKDF2-HMAC-SHA-256 是務實選項，OWASP 目前建議至少 600,000 Iterations。

資料庫到底要存什麼？讓每筆 Verifier 自我描述

一筆合格的 Credential Record 應能指出演算法、版本、成本參數、Salt 與 Hash／Tag，必要時再有 Pepper Key Version 與建立／升級時間。這不是洩漏秘密，而是讓系統能在同一遷移期正確驗證多種格式，並在登入後判斷是否需要 Rehash。

Argon2、bcrypt 與許多框架都有標準編碼格式，例如把 Variant、Version、m／t／p、Salt 與 Hash 編入單一字串。優先保存 Library 產生的完整格式，避免拆欄後遺漏參數或在不同語言間重新組裝錯誤。Pepper 本體不在此紀錄，只能保存無敏感性的 Key Version／Alias。

密碼政策應遵循 NIST：長度、Blocklist 與可用性比複雜度規則重要

NIST SP 800-63B-4 要求單因子密碼至少 15 characters；若密碼只作為 MFA 流程的一部分，可縮短但不得低於 8 characters。系統應至少允許 64 characters、接受空白與常見可列印字元、完整驗證輸入，不得靜默截斷。

NIST 不允許額外強制大小寫、數字與特殊符號的 Composition Rule，也不要求無事證的週期性改密碼。這類規則往往導致可預測的變形與重複使用。真正有效的控制是拒絕常見、情境相關與已外洩密碼，提供明確拒絕原因，並在確有外洩證據時要求更換。

登入與註冊介面要支援 Password Manager、Autofill 與 Paste，不得以禁止貼上假裝增加安全。長 Passphrase 與隨機產生的唯一密碼必須能被完整處理；前後端、API Gateway、Identity Provider 與資料庫 Driver 的上限也要一致。

外洩密碼 Blocklist 要放在建立與變更流程，不要傳出明文

註冊、變更與 Reset 時，應將候選密碼與常見、已外洩及情境相關密碼清單比對。清單至少涵蓋公開 Breach Corpus 中高頻密碼、品牌／服務名稱、Username 與容易猜測的衍生形式；若命中，要明確告訴使用者此密碼已知不安全，而不是只回傳『不符合規則』。

若使用外部 Breached Password Service，不應把完整明文、未加密 Hash 或可還原識別資訊傳給第三方。採用經評估的 k-Anonymity 前綴查詢、本地資料集或內部服務，並確認 Query Log、Cache、Telemetry 與錯誤報告不會保存候選密碼。

Blocklist 解決的是高機率猜測，不應膨脹成拒絕所有字典子字串的超大型清單。NIST 指出過大的清單增益有限，因為線上攻擊仍應由 Rate Limit 限制；過度拒絕只會迫使使用者做可預測修改。

Unicode、Normalization 與長密碼：改規則前先處理相容性

NIST 建議接受 Unicode 時，在轉成雜湊輸入前採 NFC Normalization，並提醒使用者不同端點可能有字元表示差異。這項行為一旦改變就會影響既有密碼驗證，因此必須版本化；不能在某次部署中突然對舊帳號加入 Trim、Lowercase 或不同 Normalization。

系統要明確定義『字元長度』與『Byte 長度』。一個 Unicode Code Point 可能占多個 UTF-8 bytes，bcrypt 的 72-byte 限制尤其容易與 UI 顯示的 characters 不一致。所有服務應使用同一編碼、同一正規化版本與測試向量。

極端超長輸入也可能造成 CPU／Memory DoS，應在不妨礙至少 64 characters 與 Password Manager 的前提下設合理上限，並在進入 KDF 前拒絕超限請求。拒絕必須明確，絕不能切掉後段後繼續驗證。

• 測試 composed／decomposed Unicode 是否依既定版本得到一致結果
• 跨 Web、Mobile、API、IdP 與 Batch Job 使用相同 UTF-8 規則
• 測試 64 characters、72 bytes 邊界、多位元字元與前後空白
• 任何 Normalization 改動都要有舊格式驗證與登入後 Rehash 路徑

驗證流程要避免 Timing、Enumeration 與型別混淆

密碼比較應使用框架提供的 Password Verify API 或 Constant-time Comparison，不可用一般字串 `==`。先檢查輸入長度與型別，再解析受允許的 Encoded Verifier 格式；對損毀、未知版本或過高成本參數要安全失敗並告警，避免攻擊者植入昂貴參數造成 DoS。

帳號不存在時若立即返回，而帳號存在時才執行昂貴 KDF，攻擊者可從時間差枚舉 Username。常見緩解是在不存在帳號時也對固定 Dummy Verifier 執行同類驗證，並讓 HTTP Status、Body 與可觀察時間盡量一致。

錯誤訊息要以『帳號或密碼不正確』等通用結果回覆，不能區分帳號不存在、密碼錯誤、停權或未啟用；Password Reset 同樣回覆『若帳號存在，將寄出後續指示』。內部 Log 可以記錄精確原因，但不能包含輸入密碼、Verifier、Salt 或 Pepper。

登入 Rate Limit、MFA 與 Hash Cost 必須一起設計

提高 Hash Cost 主要提高離線攻擊成本，但每次線上錯誤登入也會消耗相同伺服器資源。若只提高 Argon2id 記憶體而沒有節流，攻擊者可以用低成本請求耗盡驗證服務。Rate Limit 應以 Account 為核心，結合 IP、Device、ASN、失敗模式與風險，而不是只封鎖單一 IP。

漸進延遲、短期 Lock、Challenge 與風險型 MFA 要避免讓攻擊者能輕易鎖死大量帳號。對不存在帳號也要採近似回應；對高價值帳號與管理端點則應強制抗釣魚 MFA 或 Passkey，而不是只依賴更複雜密碼。

Hash Worker Pool、Concurrency Limit、Circuit Breaker 與 Autoscaling 是可用性控制；帳號層節流、Credential Stuffing 偵測與 MFA 是認證控制。兩者都要有 Metrics 與告警，才能分辨真實尖峰、攻擊與參數設定過重。

舊雜湊怎麼遷移？不要解密，也不要一次離線重算

系統沒有使用者的明文密碼，就不能把 MD5、SHA-1、舊 bcrypt 或低 Iteration PBKDF2 直接轉成 Argon2id。把舊 Hash 再包一層新 Hash 雖可作短期過渡，卻保留舊 Hash 作為可被猜測的內層，而且增加格式與事件應變複雜度，不應當成最終狀態。

最常見的安全遷移是 Opportunistic Rehash：每筆紀錄保留 Algorithm／Version；登入時先用舊格式驗證，成功後使用本次仍在記憶體中的原始密碼、新 Salt、目前 Argon2id 參數與 Pepper 立即產生新 Verifier，以單一原子更新取代舊值。

未再登入的帳號永遠不會自動升級，因此要設定遷移期限與 Coverage。低使用帳號可在下次登入前要求 Reset；長期休眠、高權限、已知外洩或無法辨識格式的帳號應提早失效。達到門檻並處理剩餘帳號後，移除舊 Verify Code、Library 與 Key，才能真正降低攻擊面。

• 盤點每種格式、Library、Cost、帳號數、登入頻率與 Owner
• 建立 `needsRehash` 規則，比對演算法、版本、參數與 Pepper Version
• 成功驗證後原子更新，避免並行登入覆寫新 Verifier
• 監控升級覆蓋率、失敗率、延遲與 Reset 完成率
• 設定舊格式 Sunset Date，剩餘帳號強制 Reset 後刪除舊程式碼

Pepper 輪替與外洩事件要有兩種模式

例行輪替可以採 Key Version：新密碼與 Rehash 使用目前版本，既有帳號登入時仍可在受控期限內用舊 Pepper 驗證並升級。Vault Policy 必須限制哪些工作負載可讀舊版本、保存完整 Audit Log，並設定 Retirement Date。

疑似 Pepper 外洩時不能照例行節奏慢慢等使用者登入。事件團隊要先判斷攻擊者是否也取得 Password Database；若兩者同時外洩，舊 Verifier 應視為可離線破解，依風險強制 Reset、撤銷 Session／Refresh Token、通知受影響使用者並監控 Credential Stuffing。

不要為了可輪替而把 Pepper 加密後放回同一資料庫，或讓所有服務共用一個永久 Pepper。可依 Application、Tenant 或 Credential Class 分離 Blast Radius，但分群越細，Key Lifecycle、可用性與復原程序也越複雜。

密碼變更、忘記密碼與復原流程也是 Credential Boundary

已登入的密碼變更應要求目前密碼或等效的 Step-up Authentication，避免遭竊 Session 直接改掉帳號控制權。成功變更後應產生全新 Salt 與目前參數的 Verifier，撤銷其他 Session／Refresh Token，並向使用者發送不含秘密的通知。

忘記密碼 Token 必須高熵、單次使用、短效、綁定帳號與目的，資料庫中也應以安全形式保存；回應不能透露 Email／帳號是否存在。Reset 完成後廢止所有未使用 Token，處理舊 Session，並將事件納入風險偵測。

安全問題不應作為 Password Recovery 的主要證據，因為答案常可猜測、搜尋或重複使用。對無法使用既有因子的高風險復原，要有清楚的人工作業、身分證據、雙人覆核與防社交工程程序。

不要讓密碼出現在 Log、Trace、APM、錯誤與分析工具

密碼可能在到達雜湊前被 Middleware、Reverse Proxy、Request Body Logging、APM Span、Crash Dump、Analytics Replay、Support Ticket 或測試錄影捕捉。『資料庫沒有明文』不代表整條資料流沒有明文副本。

對 Login、Register、Change Password、Reset 與 Import Endpoint 建立欄位層 Redaction，並在資料離開 Process 前處理，而不是依賴後端 SIEM 再遮罩。禁止 Debug Log 輸出 Request Body、禁止把候選密碼放進 Exception Message，也不要記錄完整 Verifier、Salt 或 Pepper。

測試與監控可記錄 Algorithm、Cost、Key Version、Verify Result、Latency、Rehash Result、Rate-limit Decision 與 Correlation ID，但不能記錄秘密值。若 APM 代理會自動抓取參數，必須用實際封包與儲存後端驗證遮罩，而不是只看設定畫面。

工程測試要驗證安全屬性，不要用真實使用者密碼

Unit Test 應確認相同密碼每次產生不同 Salt／Verifier、正確密碼可驗證、錯誤密碼失敗、格式損毀安全失敗、`needsRehash` 能辨識舊參數，以及 Unicode 與長度邊界符合版本化規則。測試向量只能使用人工資料。

Integration Test 要涵蓋 Secret Manager 暫時不可用、舊 Pepper Version、並行登入 Rehash、DB Transaction 失敗、Reset Token 重放與 Session 撤銷。Load Test 則評估 KDF 在峰值、惡意錯誤登入與擴縮容期間的 p95／p99、Memory、Queue 與 Error Rate。

Security Review 要追蹤輸入從 Browser 到 KDF 的完整 Data Flow，檢查 Proxy／Log／Telemetry／Backup 是否產生副本，並確認服務帳號只能使用必要的 Pepper Key。弱點掃描能從外部發現 TLS、認證端點、錯誤回應、Rate Limit 與部分流程問題，但無法僅靠黑箱確認資料庫內的 Argon2id 參數與 Pepper 儲存位置；這些需要程式、配置與證據查核。

常見迷思：看起來有加密，不代表能抵抗離線破解

『資料庫欄位看不懂』不是安全證據。Base64、Hex、前後加固定字串、重複 SHA-256、把 Username 當 Salt、全站共用 Salt、只在前端 Hash、或把 AES Key 放在同一份 `.env`，都無法建立正確的離線攻擊成本與信任邊界。

『Hash 後就不用保護資料庫』也錯誤。Verifier 仍是高價值認證資料，可能被破解、重放到錯誤實作，或與其他外洩資料關聯；Backup、Replica、Analytics Export 與非正式 Dump 都應採最小權限、加密、稽核與保留期限。

上線前檢查表：從演算法到事件應變一次確認

密碼安全不是單一 Library 選項，而是一條跨越 Browser、Transport、Authentication Service、Secret Boundary、Credential Store、Monitoring 與 Recovery 的控制鏈。任何一段保存明文、跳過節流、洩漏帳號存在性，或讓舊格式永久存在，都會削弱整體結果。

• 新密碼使用 Argon2id 或經合規理由核准的替代方案
• 每次設定／變更密碼產生新的 CSPRNG Salt，沒有固定或共用 Salt
• 保存演算法、版本、成本、Salt 與 Hash；Pepper 本體不進資料庫
• 正式硬體完成容量與攻擊負載 Benchmark，並有 KDF Concurrency Limit
• 單因子最小 15 characters、至少允許 64 characters，不靜默截斷
• 允許 Password Manager、Autofill、Paste、空白與既定 Unicode 規則
• 註冊／變更／Reset 阻擋常見、情境相關與已外洩密碼
• 登入具 Account-based Rate Limit、統一錯誤、近似時間與 MFA／Passkey 路徑
• Log、Trace、APM、Crash、Support 與 Backup 均不含密碼或 Pepper
• Legacy Rehash 有 Coverage、期限、強制 Reset 與舊程式碼移除條件
• Pepper 輪替、Vault 中斷、DB＋Key 外洩與 Session 撤銷已有演練
• 每年或硬體、Runtime、Library 變更後重測並提高 Cost

Redmark 在密碼安全流程中能驗證什麼？

Redmark 可在授權範圍內持續檢查公開登入、註冊、Reset 與認證後頁面，協助發現未強制 HTTPS、錯誤 Cookie／Header、資訊洩漏、部分帳號枚舉、缺少節流訊號、已知元件風險及認證流程暴露面，並在修復後持續複驗。

但黑箱掃描無法單獨證明資料庫採用何種 Argon2id 參數、Salt 是否由 CSPRNG 產生、Pepper 是否真的位於獨立 HSM／Vault，或 Log 中完全沒有密碼。這些結論需要搭配 Source Review、Configuration Evidence、IAM／Secret Audit 與效能測試。

最可靠的做法是把外部掃描、內部設計證據與修復追蹤放進同一套控制流程：掃描驗證攻擊面，工程證據驗證儲存實作，事件與 Metrics 證明控制能長期運作。