Passkey 如何運作？驗證流程指南

什麼是 Passkey？

根據 Verizon 2024 DBIR，在已確認的資料外洩事件中，有 22% 是因遭竊憑證而開啟入侵大門。憑證竊取，特別是透過 infostealer 惡意軟體與網路釣魚活動，仍然是傳統密碼式驗證中的薄弱環節。您可以從實際事件中看到這種模式：

• MGM Resorts (2023)： 攻擊者利用一通社交工程電話取得憑證，最終干擾飯店與賭場營運；MGM 揭露該季度經調整後物業 EBITDAR 受到 1 億美元衝擊，另有 1,000 萬美元一次性成本（MGM Resorts 8-K filing）。
• Colonial Pipeline (2021)： DOJ 表示，此事件源於一個用於遠端存取的帳戶遭到入侵，進而導致美國東岸大規模燃料供應中斷（DOJ press release）。
• Twilio (2022)： 一場網路釣魚活動竊取了員工憑證，進而得以存取內部系統，並對下游客戶造成影響（Twilio incident report）。

Passkey 透過綁定至特定網域的密碼學驗證來消除此類失效模式，從架構上使憑證竊取與重複使用變得不可能。

Passkey 是建立在 FIDO2 通訊協定上的密碼學驗證憑證。不同於密碼這類由您的裝置與伺服器雙方儲存的共享祕密，Passkey 使用非對稱公開與私密金鑰對密碼學。您的裝置會在安全硬體中產生並儲存私密金鑰，例如 Trusted Platform Module (TPM) 或安全隔區。對應的公開金鑰則會傳送至伺服器。在登入期間，伺服器會發出密碼學挑戰，您的裝置使用私密金鑰進行簽署，而伺服器則使用公開金鑰驗證簽章。

私密金鑰永遠不會離開您的裝置。伺服器永遠不會持有可重複使用的祕密。沒有可供網路釣魚的內容、沒有可供 stuffing 的內容，也沒有可從遭入侵資料庫中竊取的內容。

這種設計直接影響組織如何防禦針對身分基礎架構最常見的攻擊向量。

Passkey 與網路安全的關聯

Passkey 可解決企業資料外洩中最主要的初始存取類別：憑證遭入侵。Verizon DBIR 發現，整體而言有 42% 的資料外洩事件涉及遭入侵的憑證（Verizon 2024 DBIR）。傳統 MFA 方法，例如 SMS 驗證碼與 TOTP，仍然容易受到即時網路釣魚攻擊影響，攻擊者會在驗證碼過期前將其轉送至合法服務。Passkey 使用密碼學網域綁定，這表示憑證只能在合法的來源網域上運作。即使使用者與網路釣魚頁面互動，Passkey 也無法對偽造網域進行驗證。若要快速複習這些攻擊的運作方式，請參閱 SentinelOne 的網路釣魚攻擊指南。

對於管理身分基礎架構的安全團隊而言，Passkey 會將您的防禦姿態從降低憑證遭竊的機率，轉變為從架構上使其不可能發生。SentinelOne 的 身分安全總覽可協助您將驗證強化對應到更廣泛的身分風險領域。

在此背景下，可以直接比較 Passkey 所取代的內容，以及它所帶來的價值。

Passkey 與密碼比較

下表摘要說明了 Passkey 與密碼在安全性與營運層面上的核心差異，這些層面正是防禦者最關注的重點。

上述通行金鑰與密碼的比較說明了為何業界正快速轉向。下一節將拆解讓通行金鑰驗證得以運作的基本構成要素。

通行金鑰驗證的核心元件

通行金鑰驗證使用由通訊協定、硬體與平台服務組成的分層堆疊，在每個階段保護您的認證資料。每個元件都扮演特定角色，確保認證資料具備抗網路釣魚能力，並以密碼編譯方式綁定。

1. FIDO2 通訊協定堆疊：FIDO2 是由兩項核心規範組成的總體框架。WebAuthn 由 W3C Web Authentication 規範定義，是面向瀏覽器的 API，供依賴方透過 JavaScript 呼叫建立及驗證公開金鑰憑證。CTAP（Client to Authenticator Protocol）負責透過 USB、NFC 或 Bluetooth Low Energy（BLE）處理用戶端平台與驗證器硬體之間的通訊。WebAuthn 與 CTAP 共同串接您的應用程式、瀏覽器，以及保護您私密金鑰的安全硬體。
2. 驗證器類型：The FIDO Alliance authenticator specs 定義了兩種類別。平台（內嵌式）驗證器直接整合至裝置硬體中，並將私密金鑰儲存在安全隔離區或 TPM 中。漫遊式（跨平台）驗證器是可透過 USB、NFC 或 BLE 跨系統運作的外部硬體裝置，並因私密金鑰保留在專用安全元件內而提供最強的隔離性。驗證器的選擇會影響您的保證等級、復原計畫與使用者體驗。
3. 安全硬體層：每個通行金鑰的安全性都取決於驗證器對私密金鑰的保護。硬體安全金鑰透過專用安全元件提供最強保護，這些元件旨在抵禦實體與邏輯擷取攻擊。
4. 證明：在認證資料註冊期間，證明可讓您驗證通行金鑰是否建立於經核准的驗證器型號上（以其 AAGUID 識別），並符合您的安全需求，例如硬體支援的金鑰儲存或 FIPS 140-2 認證。

這四個層面——FIDO2 通訊協定堆疊、驗證器類型、安全硬體與證明——會在每次通行金鑰互動期間共同運作。下一節將逐步說明它們如何在註冊與登入期間結合運作。

通行金鑰驗證如何運作

通行金鑰生命週期包含兩個儀式：註冊（建立認證資料）與驗證（證明您持有該資料）。兩者都遵循使用公開金鑰密碼學的挑戰—回應模型。

註冊：建立通行金鑰

1. 伺服器產生挑戰。 當您啟動通行金鑰設定時，信賴方伺服器會產生一個具密碼編譯隨機性的挑戰，以及註冊參數：RP 識別碼、使用者資訊、支援的演算法（通常為 ES256）與驗證器需求。
2. 您的裝置建立金鑰組。 用戶端會呼叫 credentials. create(challenge)。您的驗證器會在安全硬體內產生新的公開／私密金鑰組。私密金鑰永遠不會離開這個受保護的邊界。
3. 回應會以簽章形式傳回。 您的裝置會將公開金鑰、認證資料 ID 與已簽署的挑戰傳送至伺服器。W3C 規範可確保完整來源會以密碼編譯方式簽署至證明物件中，將認證資料綁定至合法網域。
4. 伺服器驗證並儲存。 伺服器會確認已簽署的挑戰、驗證來源、檢查證明（適用於企業部署），並儲存與您帳戶相關聯的公開金鑰與認證資料 ID。

此時，伺服器持有您的公開金鑰與認證資料 ID，但從未見過您的私密金鑰。這種非對稱性正是讓後續每次登入都具備抗網路釣魚能力的原因。

驗證：使用通行金鑰登入

1. 伺服器發出新的挑戰。 每次登入嘗試都會產生新的具密碼編譯隨機性的挑戰，以防止重放攻擊。
2. 您的裝置對挑戰進行簽署。 用戶端會呼叫 credentials.get(challenge)。您的驗證器會提示進行使用者驗證（生物特徵掃描或裝置 PIN 碼）、擷取私密金鑰、遞增簽章計數器，並對驗證器資料與用戶端資料雜湊進行簽署。
3. 伺服器驗證簽章。 伺服器會使用您儲存的公開金鑰驗證簽章，以密碼編譯方式證明您持有私密金鑰，而該金鑰從未離開您的裝置。

遭攔截的流量不包含任何可重複利用的內容，因為每個工作階段都使用唯一挑戰。私密金鑰會持續鎖定於硬體中。您的生物特徵資料永遠不會傳送至伺服器；驗證完全在裝置上進行。

這兩個儀式都假設通行金鑰存在於您當下使用的裝置上。實務上，使用者會跨多個裝置工作，這就引出了通行金鑰如何在裝置間移動的問題。

跨平台同步

通行金鑰可以是綁定裝置，也可以在您的裝置生態系中同步。

• 已同步的通行金鑰 透過平台憑證管理器使用端對端加密進行複寫。根據 Apple 的 iCloud Keychain 文件，即使雲端帳戶遭到入侵，Apple 也無法讀取鑰匙圈內容。然而， NIST SP 800-63B 要求 AAL3 合規性必須使用不可匯出的私密金鑰，而同步 passkey 違反了這項要求，因為私密金鑰必須離開原始裝置才能進行同步。
• 裝置綁定 passkey 永遠不會離開驗證器硬體，並符合最嚴格的要求，包括 NIST SP 800-63B AAL3。同步 passkey 仍符合聯邦指南下 抗網路釣魚驗證 的 AAL2 驗證器資格。

一旦您了解裝置綁定與同步之間的決策差異，就可以評估哪些服務和平台已支援 passkey，以及採用趨勢將走向何方。

哪些服務與平台支援 Passkey

目前已有超過 150 億個線上帳戶支援 passkey 驗證，而前 100 大網站中有 48% 提供 passkey 作為登入選項（FIDO Alliance）。採用範圍涵蓋消費者平台、企業工具與金融服務。

• 作業系統與瀏覽器： Apple（iOS、macOS、Safari）、Google（Android、Chrome）與 Microsoft（Windows、Edge）都已完整整合 passkey 支援。超過 95% 的 iOS 與 Android 裝置已具備 passkey 就緒能力，而 Windows 正透過 Windows Hello 擴展同步 passkey 支援（Biometric Update）。跨裝置驗證可透過 Bluetooth Low Energy (BLE) 上的 CTAP 運作，讓您可使用儲存在附近手機上的 passkey，在筆記型電腦上完成驗證。
• 消費者平台： Google 已為超過 8 億個帳戶啟用 passkey，並表示其登入成功率是密碼的四倍。Amazon 啟用 passkey 的客戶數已超過 1.75 億。TikTok 使用 passkey 達成了 97% 的驗證成功率。其他支援 passkey 的主要消費者服務包括 PayPal、eBay、GitHub 與 Target（FIDO Alliance Passkey Index）。
• 企業與員工工具： 企業採用正在加速。HID 與 FIDO Alliance 的資料顯示，約有 87% 的企業已部署或正在積極部署 passkey。Okta、HubSpot 與 Cisco Duo 等平台已推出 passkey 支援，其中 HubSpot 回報相較於密碼與雙因素驗證，登入成功率提升 25%，登入速度快 4 倍（Dashlane Passkey Report）。
• 金融服務與政府： 包括 American Express、Bank of America 與 Wells Fargo 在內的銀行已開始推出 passkey 支援。加密貨幣交易所 Gemini 成為首批要求所有使用者必須使用 passkey 的主要平台之一。在公共部門方面，澳洲的 MyGov 服務已讓近 3,000 萬人可使用 passkey，而歐盟則推出了其 Digital Identity Wallet 架構，並將 passkey 作為核心元件。

廣泛的平台支援意味著大多數組織今天就可以開始試行 passkey。這並不表示部署毫無摩擦，下一節將說明您應規劃的營運挑戰。

實作 Passkey 的挑戰

Passkey 解決了憑證竊取問題，但在部署前也帶來了您需要規劃的營運挑戰。

• 復原安全兩難： 如果使用者遺失了唯一一台存有裝置綁定 passkey 的裝置，且未註冊任何備份，則在沒有備援機制的情況下，該帳戶實際上將無法復原。使用電子郵件或 SMS 的傳統復原流程，會重新引入 passkey 原本旨在消除的那些弱點。
• 舊有系統相容性： 較舊的應用程式經常缺乏 FIDO2/WebAuthn 支援。根據 FIDO Alliance 的 enterprise passkeys paper，聯邦式環境可在 IdP 層級實作 passkey，讓下游支援得以在無需個別修改的情況下啟用。非聯邦式環境則必須在每個應用程式中個別實作 FIDO，或先遷移至聯邦式模型。
• 組織與跨平台障礙： 即使具備強大的安全優勢，passkey 部署仍可能因資源配置、權責歸屬與流程變更而停滯。Passkey 行為也會因平台與瀏覽器而異，不同的註冊流程與同步行為會使訓練更複雜，並在推行期間增加支援負擔。

這些挑戰都不是阻礙因素，但每一項都需要在規劃期間做出審慎決策，而不是在上線後再補救。以下最佳實務將直接處理復原、相容性與推行摩擦問題。

企業部署 Passkey 最佳實務

成功的 passkey 推行需要架構規劃、分層政策與分階段執行。

• 建立雙層憑證策略： 依據風險設定檔與保證等級需求區分您的使用者群體。需要符合 AAL3 的特權帳戶（管理員、財務、受監管存取）應使用裝置綁定 passkey 或具備不可匯出私密金鑰的硬體安全金鑰。一般員工使用者則可使用同步 passkey（符合 AAL2 抗網路釣魚要求），以提升可用性，並透過其裝置憑證管理器獲得平台支援的復原能力。
• 分三個階段部署： 實施結構化推行：先在高價值應用程式（電子郵件、VPN、HR 系統）中，以 50 到 100 名使用者進行試點，建立生命週期與復原流程。接著擴展至更多應用程式與使用者區段，同時正式化佈建、撤銷與稽核工作流程。最後，將 passkey 設為預設驗證方法，並將以密碼為基礎的備援降為僅限緊急情況使用。
• 先聯邦化，再部署： 如果您的驗證架構尚未透過 Identity Provider 集中化，請先處理這一點。在 IdP 層級實作 passkey 的聯邦式環境，可以在無需個別修改的情況下支援下游應用程式。非聯邦式環境則面臨更耗費資源的路徑，需要在每個應用程式中個別支援 passkey。
• 設計抗網路釣魚的復原機制： 逐步淘汰 SMS 與電子郵件式復原，改採具時間限制的復原機制與備份 passkey。復原權杖應具有 5 到 15 分鐘的到期視窗、綁定至來源工作階段，並強制一次性使用。註冊於次要裝置上的備份 passkey 可提供最強的備援，因為它們保留了主要驗證的密碼學安全特性。
• 要求企業註冊進行證明： 實作基於 AAGUID 的證明篩選，以確保只有經核准的驗證器型號可以註冊憑證。這可防止使用者在不符合您硬體安全要求的驗證器上註冊 passkey。
• 投資於目標式訓練： 訓練計畫應涵蓋不同裝置類型上的 passkey 註冊、遺失裝置的復原程序、備援驗證的使用，以及政策變更背後的安全理由。跨平台不一致性使實作型訓練比單靠文件更有效。
• 從第一天起實作稽核記錄： 在您的 SIEM 中追蹤每一次註冊事件、驗證嘗試、復原動作與憑證撤銷。整合 passkey 生命週期事件，以維持支援 ISO 27001 控制目標與 SOC 2 CC6 邏輯存取安全要求的稽核軌跡。SentinelOne 的 SIEM 指南 和 XDR 概覽 可協助您將身分遙測與端點及雲端訊號對齊。

這些營運基礎可協助您將 passkey 轉化為可供稽核的控制措施，而這正是合規與監管機關期望開始發揮作用之處。

Passkey 驗證的合規與監管驅動因素

監管壓力正在加速 passkey 的採用。CISA 敦促每家企業為電子郵件、VPN，以及涉及關鍵基礎設施的系統實作具抗網路釣魚能力的 MFA。CISA 與 NIST 也已發布一份 跨機構報告草案，內容關於保護驗證權杖免於遭到竄改、竊取與重放攻擊。NIST SP 800-63B 規定，AAL2 需要具抗網路釣魚能力的選項，而 AAL3 則需要具抗網路釣魚能力且具有不可匯出私鑰的驗證器。

若要讓 passkey 符合稽核要求，通常需要展示三件事：

• 控制對應：記錄 passkey 如何滿足或超越現有的存取控制目標（例如 ISO 27001 附錄 A 的存取控制要求）。
• 風險評估：記錄您引入的風險（裝置遺失、供應商鎖定、復原複雜性、降級攻擊）以及您的補償控制措施。
• 證據與強制執行： 維護實作文件、證明政策已強制執行，並保留驗證與復原事件的稽核軌跡。

將這些項目整合在一起，可讓您將 passkey 定位為同時兼具安全升級與稽核友善的控制措施組合。不過，驗證只是身分攻擊面的一層，而您圍繞 passkey 建置的工具，將決定當威脅超出登入提示範圍時，您能多快偵測並回應。

使用 SentinelOne 強化 Passkey 驗證

Passkey 可在驗證層消除以憑證為基礎的攻擊，但身分安全不僅止於登入提示。工作階段權杖竊取、橫向移動，以及以身分為基礎的持續性存取，皆發生在驗證之後。 Singularity Identity 會關聯端點與身分活動，以進行情境驅動的偵測，並在 passkey 只是部分情況時加快分級處理。它可強化 Active Directory 與雲端身分提供者，包括 SecureAuth、Ping、Duo、Entra ID 和 Okta，部署欺敵技術以提早誘捕入侵者，並即時偵測憑證竊取與權限提升。

Purple AI 透過將自然語言查詢轉換為跨領域搜尋，加速與身分相關警示的調查。使用 Purple AI 的組織回報威脅修復速度最高可提升 55%，調查時間可減少 40-50%（IDC 研究）。

在獨立的 2024 MITRE ATT&CK Evaluations 中，SentinelOne 產生的警示數量比所有供應商的中位數少 88%（MITRE ATT&CK Evaluations 結果），協助您的團隊將時間花在真實事件上，而非警示數量上。

當您集中管理 passkey、端點與身分遙測時， Singularity AI SIEM 可讓您在單一位置熱儲存標準化的安全事件，以加快威脅狩獵與鑑識。SentinelOne 的 cybersecurity 101 中心 提供可支援內部 runbook 的相關概念。 註冊 SentinelOne 示範，了解身分、端點與雲端遙測如何在單一平台中整合。

Reduce Identity Risk Across Your Organization

Detect and respond to attacks in real-time with holistic solutions for Active Directory and Entra ID.

Get a Demo

重點整理

passkey 的核心是什麼？它是一種加密憑證，以非對稱式密碼學取代共用祕密，消除造成 22% 資料外洩事件背後的憑證竊取風險（Verizon 2024 DBIR）。企業部署需要雙層憑證策略：針對符合 AAL3 的特權帳戶使用裝置綁定 passkey，並為一般員工使用同步式 passkey。 

建立具抗網路釣魚能力的復原工作流程、聯合您的驗證架構，並分階段推出。來自 CISA 與 NIST 的監管要求正在加速採用。