Passkey 運作方式與導入指南

基於 WebAuthn / FIDO2 標準的無密碼驗證機制

一、Passkey 運作原理

核心概念

Passkey 基於 WebAuthn / FIDO2 標準，使用非對稱加密（公私鑰）取代傳統密碼：

私鑰：保存在使用者裝置的安全硬體中（Secure Enclave、TPM、YubiKey 等），永遠不離開裝置
公鑰：註冊時上傳到網站伺服器儲存
驗證方式：使用者透過生物辨識（Face ID、指紋）或裝置 PIN 解鎖私鑰，對伺服器發來的 challenge 簽名

註冊流程（Registration）

1. 使用者點「建立 Passkey」
2. 伺服器產生 challenge + 使用者資訊 → 回傳給瀏覽器
3. 瀏覽器呼叫 navigator.credentials.create()
4. 作業系統提示生物辨識
5. 裝置產生金鑰對，私鑰存本地，公鑰簽名後回傳
6. 伺服器驗證簽章並儲存 (credentialId, publicKey, userId)

登入流程（Authentication）

1. 使用者輸入帳號（或選擇 Passkey）
2. 伺服器產生 challenge → 回傳
3. 瀏覽器呼叫 navigator.credentials.get()
4. 裝置以生物辨識解鎖私鑰，簽署 challenge
5. 伺服器用儲存的公鑰驗證簽章 → 登入成功

安全特性

防釣魚：簽章綁定 origin（domain），假網站無法重用
無共享密碼：伺服器外洩也無法被用來登入
跨裝置同步：iCloud Keychain、Google Password Manager、1Password 等可同步 Passkey

二、從密碼系統導入 Passkey 的常見做法

方式 1並行支援（最常見、推薦起步方式）

保留密碼登入，將 Passkey 作為額外的登入方式。

使用者登入後，在「帳號安全」頁面新增 Passkey
下次登入可選擇密碼 or Passkey
適合：漸進式遷移，風險最低
範例：Google、GitHub、Microsoft 都採此路線

方式 2升級式（Passwordless Upgrade）

使用者建立 Passkey 後，提示「停用密碼」或將密碼降級為 fallback。

Apple ID、Microsoft 帳號採用此模式
需搭配多裝置同步避免單點失敗

方式 3雙因素替代（2FA Replacement）

把 Passkey 當作 TOTP/SMS 的替代品，密碼仍為主驗證。

適合監管嚴格、無法立刻移除密碼的環境（銀行、企業 SSO）

方式 4全新註冊改 Passkey 優先

新使用者註冊預設使用 Passkey，舊使用者維持密碼直到自願升級。

三、技術導入步驟

階段	工作項目
後端	引入 WebAuthn 函式庫：Node `@simplewebauthn/server`、Go `go-webauthn`、Python `py_webauthn`、Java `webauthn4j`
資料庫	新增 credentials 資料表：`credential_id`, `public_key`, `user_id`, `sign_count`, `transports`, `aaguid`
前端	使用 `@simplewebauthn/browser` 或原生 `navigator.credentials` API
RP 設定	設定 `rpId`（domain）、`origin`、`user verification` 策略
UX	加入 Conditional UI（autofill 帶出 Passkey）、跨裝置 QR Code 登入流程
Recovery	規劃帳號復原機制：備用 email、recovery code、客服管道

導入時要避開的坑

rpId 設定錯誤：必須是 effective domain（如 example.com），子網域才能共用
sign_count 驗證：偵測 credential 被複製，但雲端同步的 Passkey 可能永遠是 0，需放寬
多 Passkey 管理：使用者可能有手機、筆電、安全金鑰多個 credentials，UI 要支援命名與刪除
跨平台同步差異：iCloud Keychain ↔ Google Password Manager 之間目前無法直接同步，需引導使用者每個平台各註冊一次，或使用第三方密碼管理器

四、裝置遺失時的 Passkey 復原機制

這是 Passkey 設計上最棘手的問題——沒有密碼可以打回原形，所以「帳號復原」必須事先規劃好。以下是業界常見做法：

1. 雲端同步（最主流的第一道防線）

現代 Passkey 預設透過雲端密碼管理器同步，裝置遺失 ≠ Passkey 遺失。

平台	同步機制	復原方式
Apple	iCloud Keychain	用 Apple ID 登入新裝置 → Passkey 自動同步
Google	Google Password Manager	用 Google 帳號登入 Chrome/Android → 同步
Microsoft	Microsoft 帳號	透過 Authenticator app 同步
1Password / Dashlane	自家雲端	主密碼解鎖 vault

關鍵觀念：Passkey 不再綁定單一裝置，而是綁定「使用者的雲端身分」。真正的 root credential 是 Apple ID / Google 帳號本身。

⚠ 但這會把問題往上推一層：如果 Apple ID 也被鎖死怎麼辦？所以網站不能假設使用者一定能從雲端救回來。

2. 註冊多個 Passkey（推薦做法）

引導使用者在多個裝置註冊 Passkey，互為備援：

手機 + 筆電 + 平板各一個
加上一隻硬體安全金鑰（YubiKey）放在抽屜
一台遺失，其他仍可登入

UX 設計重點：

註冊第一個 Passkey 後，主動提示「建議新增第二個裝置」
帳號安全頁面顯示所有 credentials，可命名（「我的 iPhone」「公司 MacBook」）並單獨刪除遺失的那個

GitHub、Google 都採此做法。

3. Recovery Codes（備用恢復碼）

註冊 Passkey 時，產生 8–10 組一次性恢復碼，要求使用者印出或存到安全位置。

ABCD-1234-EFGH
WXYZ-5678-IJKL
...（共 10 組，每組用一次）

適合：使用者無其他裝置時的最後手段
範例：GitHub、Discord、Cloudflare 都提供
缺點：使用者經常忘記存在哪、印出後弄丟

4. 備用 Email / 手機驗證

回到傳統的「忘記密碼」流程，但用來重新註冊新的 Passkey：

1. 使用者點「無法登入」
2. 系統寄驗證連結到註冊 email（或簡訊 OTP）
3. 點連結 → 進入「建立新 Passkey」流程
4. 舊的 Passkey 被標記為失效

⚠ 這條路把安全性降到「email 帳號的安全程度」——如果 email 也用 Passkey 保護就還行，如果 email 仍用弱密碼，整個 Passkey 系統的防護就被打穿了。

5. 社交復原（Social Recovery）

讓使用者預先指定 2–3 位信任聯絡人，遺失時由他們協助驗證身分。

範例：Apple 的「帳號恢復聯絡人」、部分加密貨幣錢包
一般網站較少採用，UX 與信任成本高

6. 人工客服 / KYC 驗證

最後手段：使用者打客服，提供身分證件、回答安全問題、或視訊驗證。

銀行、證券、政府網站幾乎必備
一般網站較少做，因為成本高且本身是釣魚目標
通常會搭配「冷凍期」（如 7 天後才能重設）防止社交工程攻擊

業界實際組合範例

網站	主要復原策略
Google	雲端同步 + 多裝置 + Recovery code + 信任聯絡人 + 備用 email/手機
GitHub	多 Passkey + Recovery code + SSH key fallback
Apple ID	iCloud Keychain + 信任聯絡人 + 復原金鑰 + 客服（含 7 天冷凍期）
銀行 App	雲端同步 + 臨櫃 / 視訊 KYC

設計建議

針對「從密碼遷移到 Passkey」的網站，推薦的最低組合：

✓ 強制要求至少 2 個 Passkey（或 1 個 Passkey + 1 個 Recovery code 集）
✓ 保留驗證過的 email/手機作為次要復原管道
✓ 帳號安全頁面清楚顯示所有 credentials，支援命名、刪除
✓ 復原流程加入冷凍期 + email 通知，防止帳號被劫持
⚠ 高風險操作（轉帳、改 email）即使登入了也要額外重新驗證 Passkey

一個常被忽略的根本權衡

Passkey 帶來的安全提升，本質上是把「使用者記得密碼」的責任，換成「使用者保管裝置 / 雲端帳號」的責任。復原機制設計的核心問題是：

你願意讓「攻擊者拿到 email 存取權」就能重設帳號嗎？

如果答案是「不」，那就不能只靠 email 復原，必須額外要求 recovery code 或多裝置驗證。這是 Passkey 時代帳號安全設計最關鍵的取捨。

參考：W3C WebAuthn Level 2 · FIDO Alliance Passkeys