密碼管理器推薦

一般使用主密碼登入的 Bitwarden 帳號，客戶端以主密碼和帳號信箱等輸入進行 KDF，取得 Master Key。再經 HKDF 展開得到 Stretched Master Key，用它解開從伺服器取回的 Protected Symmetric Key，得到 User Symmetric Key。資料解密在客戶端執行。這裡展示的是概念流程，省略個別項目加密金鑰與其他登入方式。[01]

Master Password + account salt
    ↓ KDF (PBKDF2 或 Argon2id)
Master Key
    ↓ HKDF（展開不同用途的金鑰材料）
Stretched Master Key
    + 伺服器保存的 Protected Symmetric Key
    ↓ 在本機解開
User Symmetric Key
    ↓ 解開 Vault 項目相關金鑰與密文
Vault 明文（只在授權裝置需要時使用）

注意區分「驗證登入」與「解密 Vault」：登入通常還會使用可供服務端驗證的衍生雜湊及 MFA；解密則是拿到真正的對稱金鑰。改主密碼、調 KDF 參數、輪替 Vault 加密金鑰是不同作業，不能認為改了密碼就讓攻擊者已保存的舊密文瞬間失效。[22]

KDF 的輸入是人類容易記憶、熵可能不足的主密碼；用鹽值（salt）與昂貴的計算，讓攻擊者對每個猜測都必須重新付費。Salt 通常不需要保密，目的是讓相同密碼在不同帳號上得到不同的輸出，並提高預先計算表的重複利用難度。

PBKDF2-HMAC-SHA256(P, salt, c, dkLen)
P      = 主密碼
salt   = 非秘密的鹽值
c      = 迭代次數
 dkLen = 需要輸出的金鑰長度

Argon2id(P, salt, m, t, p)
m = 記憶體成本
 t = 時間／迭代成本
 p = 平行度

Bitwarden 文件中的預設參考：PBKDF2-HMAC-SHA256：600,000 iterations；Argon2id：32 MiB、6 iterations、parallelism 4。PBKDF2 主要增加重複計算；Argon2id 同時要求記憶體，讓高平行猜測不那麼便宜。600,000 不能直接和 6 比較，因為工作模型完全不同。[02]

簡化成本模型：總猜測時間 ≈ 猜測次數 × 單次猜測成本 ÷ 有效並行量。但 GPU、記憶體頻寬、KDF 參數與硬體配置會大幅改變結果，不能直接用解鎖秒數換算出可靠破解時間。長且獨立的主密碼仍是第一條防線。

「AES-256」表示金鑰長度，不表示整套加密協定的安全性。除了加密資料本身，還需要完整性驗證，否則攻擊者可能修改密文而無法被可靠察覺。

• Bitwarden：AES-256-CBC + HMAC-SHA256。CBC 負責機密性，HMAC 額外驗證密文完整性；安全性也依賴正確的 IV、金鑰分離與驗證順序。
• 1Password：AES-256-GCM。GCM 是 AEAD 模式，將加密與驗證整合；同樣需要妥善管理 nonce／IV，不能重複使用不該重複的 nonce。

不能單憑 CBC 或 GCM 的名字判斷整個產品哪個比較安全；端點、金鑰管理與事故復原往往同樣重要。[03][05]

TOTP 基於 HOTP。網站和驗證器共享一個隨機秘密種子 K，把目前時間映射成計數器 T，再以 HMAC 的結果轉成短數字。[11]

T = floor((UnixTime − T₀) / X)
H = HMAC(K, encode_8_byte_big_endian(T))
OTP = DynamicTruncate(H) mod 10^d

K  = 共享秘密種子
T₀ = 基準時間（常見 Unix epoch）
X  = 每個時間窗的秒數（常見 30）
d  = 輸出位數（常見 6）

RFC 6238 支援 HMAC-SHA-1／256／512 方案，實際服務的 seed、位數和時間窗必須相容。六位碼總共只有 10^6 種可能，因此服務端需要登入失敗速率限制，並處理時間誤差與重放檢查；不是把 30 秒內任何無限次猜測都視為合理。

QR Code 內往往包含秘密種子或可還原種子的設定 URI；不要把它當一般登入 QR Code 分享到群組。拿到 K 的人可以在後續時間窗自行算出驗證碼。

註冊（registration）時，驗證器為特定 RP 建立公私鑰對，網站保存 Public Key 與 Credential ID。登入（authentication）時，網站下發不可預測的 Challenge；瀏覽器／驗證器產生 Assertion，伺服端驗證。[13]

註冊：
  Authenticator → (private key, public key)
  Server        ← public key + credential ID

登入：
  Server → challenge
  Authenticator → signature over
    authenticatorData || SHA256(clientDataJSON)
  Server checks:
    challenge / type / Origin
    rpIdHash / UP・UV flags（依政策）
    signature / credential binding

Origin 表示呼叫 WebAuthn API 的網站來源；RP ID 是憑證被允許使用的依賴方範圍。假站不能隨意冒用真站的 RP ID 或替真站取得有效斷言；服務端也必須確實檢查，不可只驗簽章後忽略上下文。

「防釣魚」不等於「防所有帳號接管」：已登入的 Session Cookie、惡意瀏覽器擴充套件或弱式復原流程仍可能成為其他入口。[12]

Passkey 是運用 FIDO 憑證完成登入的一種方式。使用指紋、臉部辨識或裝置 PIN 時，通常是在本機解鎖驗證器，不是把生物辨識資料送給網站。

• Device-bound：憑證綁定於特定驗證器／裝置，硬體隔離通常較明確，但要準備備用金鑰。
• Synced Passkey：可透過提供者保護的同步體系在多裝置使用，恢復較方便，應特別保護同步帳號與裝置。

不能把「私鑰永遠不可匯出」套到所有 Passkeys。實際能否登入與解鎖密碼管理器的 Vault，也可能是不同機制；例如某些設計還需要 WebAuthn PRF 支援才能從 Passkey 衍生 Vault 解密材料。[01][13]

1Password 在裝置上產生具有約 128 bits 熵的 Secret Key，與 Account Password 一起參與帳號加密金鑰的保護。它不是帳號序號，也不是第二個要背的密碼；Secret Key 會保存在授權裝置及適當的 Emergency Kit。[04]

SRP（Secure Remote Password） 用於登入身分驗證，不等於 Vault 的資料加密；其設計目標是讓服務端能進行密碼證明，而不必接收使用者輸入的原始 Account Password。[19]

攻擊者只拿到伺服器加密資料時，缺乏 Secret Key 是額外的離線攻擊障礙；但如果他同時控制已授權裝置、取得 Secret Key 或復原資料，就不能照搬「純伺服器外洩」的安全推論。

Bitwarden 的 Base domain 會參考有效註冊網域；Host 約束主機名稱；Exact 要求整個 URI 完全相符。敏感子網域有時應改用 Host／Exact，但 Exact 可能因路徑或 query string 變動而失效。Android、iOS 的可比對資訊還可能受到 OS API 限制。[18]

Bitwarden 的「Autofill on page load」預設關閉；官方也提醒受攻擊的網站可能利用這個便利性。使用者手動觸發、檢查網址、避免可疑 iframe 都有意義；但一旦憑證真的填進惡意的頁面欄位，光靠 URL 配對無法阻止網頁腳本讀取當前欄位。[09]

剪貼簿清除計時只能降低殘留時間，不應被視為防止所有剪貼簿讀取的安全沙箱。

跨裝置同步主要維持目前資料一致，不等於你能在帳號被鎖、設備都遺失時取回舊資料。以 Bitwarden 為例，Password protected encrypted JSON 用另設密碼保護且可匯入別的帳號；Account restricted 則依賴原帳號的加密金鑰，不宜當作唯一的跨帳號災難備援。[16]

一般的加密 JSON 匯出不含檔案附件。含附件的 ZIP 匯出還應另外使用加密容器保護，不能因為副檔名是 ZIP 就以為已加密。復原資料必須在 Vault 無法登入時也拿得到。

最簡單的實際演練：確認離線保存的復原碼能找到、備份檔能解密、測試環境能匯入、附件另行檢查。必要時先在隔離環境操作，不要為測試而在共用電腦輸入真的主密碼。