通行金鑰為何能抵抗網路釣魚？解析 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；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 是手動轉交的短效驗證碼；通行金鑰則讓驗證器使用與服務綁定的私密金鑰產生簽章，由服務以公開金鑰驗證。

這個差異說明了抗網路釣魚能力，也說明實作責任：註冊必須把正確的金鑰連到正確帳號，登入必須同時驗證簽章與請求條件。裝置新增、復原及客服流程也要維持相同的安全邊界。

把通行金鑰當成完整的身分驗證設計，而不只是多一顆登入按鈕，才能發揮它的價值。