通行密鑰為何能抵抗網絡釣魚？WebAuthn、FIDO2 與公開密鑰登入原理

傳統登入會把用戶輸入的密碼傳送給伺服器。妥善的實作會儲存加鹽的密碼雜湊，而非明文，但用戶仍要在登入時提交同一個可重複使用的秘密。

通行密鑰改用一對密鑰。驗證器（authenticator）或憑證提供者管理私鑰，服務儲存對應的公開密鑰。伺服器為登入發出新的挑戰值（challenge），驗證器簽署包含該挑戰資訊的資料，服務再驗證簽署。

密碼登入：
  用戶 -> 伺服器：密碼
  伺服器：與已儲存的密碼雜湊比對

通行密鑰登入：
  伺服器 -> 瀏覽器：challenge
  驗證器：簽署 authenticatorData || SHA-256(clientDataJSON)
  瀏覽器 -> 伺服器：驗證回應及簽署
  伺服器：以公開密鑰驗證簽署，並檢查請求條件

以上只是流程示意，並非完整實作。密碼外洩後可能被重用；單靠外洩的公開密鑰，卻不能產生有效登入簽署。私鑰不會交給登入服務的伺服器。同步通行密鑰的提供者可能透過端對端加密，在用戶的裝置之間同步密鑰資料；這與把密鑰交給登入服務是兩個不同邊界。

WebAuthn 是讓網頁應用程式建立和使用公開密鑰憑證的瀏覽器 API。WebAuthn Level 3 於 2026 年 8 月 25 日成為 W3C Recommendation，定義應用程式、瀏覽器、驗證器和依賴方之間的互動。

通行密鑰是供無密碼登入使用的 FIDO 可探索憑證（discoverable credential）；不是所有 WebAuthn 憑證都稱為通行密鑰。FIDO2 結合 W3C WebAuthn 與 FIDO CTAP，後者處理與外部驗證器通訊等情境。

用戶毋須自行構思通行密鑰的內容。新的密鑰對由驗證器產生。

1. 伺服器提供用戶識別碼、RP ID、挑戰值、允許的演算法及其他註冊選項。
2. 網頁應用程式在瀏覽器內呼叫 navigator.credentials.create({ publicKey: ... })。
3. 驗證器確認所需操作。指紋、面容或 PIN 所做的用戶驗證（UV），與觸碰保安密鑰等用戶在場確認（UP）不同；觸碰本身不證明操作者是誰。
4. 驗證器產生私鑰及公開密鑰。
5. 伺服器檢查回應 type、已發出的 challenge、允許的 origin、RP ID 雜湊、所需 UP／UV 旗標、演算法和 attestation 政策，然後才將憑證 ID、公開密鑰等資料綁定至正確帳戶。

服務收到的是公開密鑰及憑證資訊，不是私鑰。同步提供者可能把加密的密鑰資料傳到另一裝置，但 RP 不會因此收到私鑰。

向現有帳戶新增通行密鑰，必須先透過適當的身份驗證或重新驗證，確認操作者有權新增，並把註冊作業綁定至該帳戶。建立全新帳戶屬於另一註冊流程。有效的註冊回應或裝置 UV，不能單獨證明操作者有權替所聲稱的現有帳戶加入憑證。

驗證器證明（attestation）可供 RP 評估驗證器的特性或來源，在企業或較高保證要求的環境可能有用，但也涉及私隱和部署成本。一般服務可選擇不要求能識別驗證器來源的證明。

登入時，伺服器要求驗證器證明它能使用已登記的私鑰，而且這份回應是為今次驗證產生。

1. 用戶開始登入。
2. 伺服器回傳不可預測的挑戰值及驗證條件。不先輸入用戶名稱的流程可省略 allowCredentials，或將它設為空陣列。
3. 網頁應用程式在瀏覽器內呼叫 navigator.credentials.get({ publicKey: ... })。
4. 驗證器完成所要求的用戶驗證或在場確認。
5. 驗證器簽署 authenticatorData 與 SHA-256(clientDataJSON) 串接後的位元組。challenge 和 origin 位於 clientDataJSON，透過雜湊納入簽署。
6. 伺服器以已儲存的公開密鑰驗證簽署，並檢查 challenge、origin、RP ID、操作類型、所需旗標和帳戶對應。

要防止重放攻擊，伺服器須發出足夠隨機的挑戰值，綁定至待完成作業、檢查期限，而且只接受一次。簽署有效不等於可以接受重複回應。NIST 亦將 nonce 或 challenge 視為抗重放協定的機制。

用戶可能覺得是「用指紋登入」，但指紋影像不會傳給服務。生物認證或 PIN 是在本機授權使用密鑰的操作。

WebAuthn 的登入簽署並非只涵蓋 challenge。輸入是 authenticatorData || SHA-256(clientDataJSON)，|| 表示位元組串接。必須對收到的原始 clientDataJSON 位元組計算雜湊，不能先解析再重新序列化 JSON 來代替。RP ID 雜湊是 RP ID 字串的 SHA-256。

伺服器除了驗證簽署，也要檢查 challenge 是否由自己發出、origin 是否獲准、RP ID 雜湊是否相符，以及必要旗標是否成立。數學上正確的簽署，不能令不獲准的來源或過期挑戰值變得有效。

簽署計數器只是輔助訊號。有些驗證器一直回傳 0，同步憑證的計數器亦不能一概假設為單調遞增，因此不能只憑數值便斷定憑證被複製。應使用成熟的 WebAuthn 程式庫並遵循完整註冊及驗證程序；本文重點不是自行實作伺服器端驗證邏輯的完整清單。

保障來自簽署、瀏覽器的網站限制、請求條件和驗證器檢查的配合，不是單靠一般數碼簽署 API。

通行密鑰的抗網絡釣魚能力不依賴用戶每次都看出網址差異。NIST 將這種能力描述為避免向假冒驗證方交出認證秘密或有效認證輸出；WebAuthn／FIDO2 使用驗證方名稱綁定。

憑證的使用範圍由 RP ID 限定。為 example.com 建立的通行密鑰，不能直接由外觀相似的 examp1e.com 使用。

真正網站：https://example.com
  example.com 的憑證 -> 可用於這個網站

假冒網站：https://examp1e.com
  example.com 的憑證 -> 這個網站不能直接使用

RP ID 通常是 origin 的主機名稱或允許的上層網域，不含 scheme 或連接埠。origin 包括 scheme、主機和連接埠，RP 還要另外驗證允許的 origin。Related Origin Requests 等機制可容許明確設定的例外，不能把所有 WebAuthn 情境都理解為主機名稱必須完全相同。

origin 納入已簽署的資料，單純複製畫面並不足以取得真正服務可接受的登入。通行密鑰流程沒有要求用戶把可轉用的密碼或驗證碼交給假表單。

在密碼以外加入獨立的持有因素，例如適當設計的 TOTP 或短訊確認，可加強雙重認證。單靠一組驗證碼不會自動變成兩個因素，TOTP 亦不一定是六位數。短訊還有 SIM 卡被冒名補領或電話號碼被轉移等風險。

手動輸入的驗證碼可能被即時轉送：假頁面收集驗證碼，再趁有效時提交至真正網站。NIST 不把這類手動輸入的認證輸出視為具備抗網絡釣魚能力，因為它未以阻止轉送所需的方式綁定至特定驗證會話。

這不代表 TOTP 沒有用途。適當加入的因素可以補強只用密碼的不足；WebAuthn 則以服務綁定來處理手動驗證碼容易被轉送的問題。

部分憑證可在裝置間同步，部分則固定於某部裝置或保安密鑰。提供者可透過端對端加密同步密鑰資料，方便換機後繼續使用；裝置綁定方式的密鑰移動範圍較小，但遺失或故障時須有復原安排。

一般服務可能較重視同步方式的便利。管理員帳戶、企業管理裝置或較高保證要求的環境，則可能需要配合保安密鑰、裝置管理、attestation 政策及多組憑證。不能只憑類型名稱便判定符合所有保安要求。

可探索憑證讓驗證器不用先收到 RP 提供的憑證 ID 清單，也能找到帳戶對應的憑證，支援毋須先輸入用戶名稱的登入方式。

傳統流程通常先輸入帳戶及密碼，再使用驗證碼或保安密鑰。通行密鑰可由瀏覽器或作業系統的憑證管理工具，列出符合目前 RP ID 的帳戶選項；用戶選取後完成所需驗證。

介面仍要考慮共用電腦會顯示哪些帳戶、家庭成員會否選錯，以及公司裝置是否容許個人通行密鑰。帳戶選擇、說明文字和裝置政策同樣重要。

通行密鑰加強登入，卻不會自動保護所有復原途徑。較弱的復原程序仍可能繞過原有保障。

例如平日登入必須使用通行密鑰，復原卻只需電郵中的驗證碼，攻擊者便可能改為入侵電郵帳戶。新增可信任裝置、多組憑證、後備碼和客戶支援程序，都應納入設計。

• 在服務支援時，為重要帳戶登記多組通行密鑰。
• 同一組同步通行密鑰在多部裝置可用，並不代表獨立於同步帳戶；可考慮另一復原方法或獨立登記的保安密鑰。
• 為同步帳戶本身設定強健的身份驗證。
• 保持復原電郵地址和電話號碼有效。

目標是讓合法用戶能恢復存取，同時避免為攻擊者提供更容易的入口。

瀏覽器和驗證器無法補救所有伺服器端錯誤。

• 重用 challenge：挑戰值須不可預測、短時間有效、綁定至待完成作業，而且只接受一次。
• 缺少 origin／RP ID 檢查：簽署正確之外，也要符合允許的來源及預期 RP。
• 混淆 UP 與 UV：需要用戶驗證時，指定 userVerification: "required"，並在伺服器確認 UV 旗標。
• 憑證對應錯誤：管理好憑證 ID、公開密鑰、帳戶之間的關係及新增權限。
• 復原途徑薄弱：檢查所有新增或更換憑證的入口。

用戶亦需要知道密鑰可在哪些裝置使用、會否同步，以及能否用於公司裝置。說明應交代操作和後果，不應假設用戶熟悉密碼學術語。

通行密鑰主要改善登入憑證被網絡釣魚竊取的問題。惡意程式仍可能劫持登入後的會話；授權漏洞、會話固定攻擊、跨網站指令碼（XSS）、OAuth 設定錯誤和假冒客戶支援，都要另行處理。

若用戶被騙而將攻擊者的裝置或憑證加入帳戶，仍可能失去帳戶控制權。遙距支援騙案、未受管理的裝置和營運程序，也超出一般假登入頁面的防護範圍。

這些限制不會抹去通行密鑰的作用。公開密鑰憑證與服務綁定，可以阻止一類常見的密碼及驗證碼竊取、轉送攻擊，但要配合安全的會話、授權、登記和復原流程。

密碼是用戶提交的秘密；TOTP 是手動轉交的短效驗證碼；通行密鑰則由驗證器使用與服務綁定的私鑰產生簽署，服務以公開密鑰驗證。

這個分別同時解釋抗網絡釣魚能力和實作責任：註冊要把正確密鑰連到正確帳戶，登入要同時檢查簽署和請求條件。新增裝置、帳戶復原及客戶支援也要維持這個邊界。

把通行密鑰視為完整身份驗證設計，而不只是多一個登入按鈕，才能發揮它的保障。