Skip to main content
身分安全

什麼是 Passkey?現代驗證基礎

Passkey 使用加密金鑰配對來取代密碼,消除網路釣魚與憑證竊取。了解其運作方式與部署最佳實務。

作者 SentinelOne
Reviewer: Jeremy Goldstein
什麼是 Passkey?現代驗證基礎

什麼是 Passkey?

攻擊者釣取員工的密碼、繞過 SMS 雙因素驗證,並在您的網路中橫向移動。根據 Verizon DBIR,在以憑證為基礎的攻擊模式中,88% 的資料外洩事件涉及遭竊憑證,而在 57% 的社交工程事件中使用了網路釣魚。

Passkey 可消除此整條攻擊路徑。它們使用加密式、無密碼驗證,私密金鑰永遠不會離開使用者裝置,使得 憑證竊取 在實務上幾乎不可能。

Passkey 依賴公開金鑰密碼學。您的裝置會產生一組唯一的金鑰配對:私密金鑰保留在您裝置上的硬體保護儲存區中,例如 Trusted Platform Module 或 Secure Enclave,而公開金鑰則提供給服務供應商。在驗證期間,服務會傳送一個挑戰,由您的裝置使用私密金鑰進行簽署。沒有任何密碼會穿越網路。這消除了 網路釣魚、憑證填充與密碼重複使用攻擊,因為私密金鑰永遠不會離開裝置,也不會傳輸任何可重複使用的秘密資訊。

Passkey 實作 FIDO2 標準(WebAuthn + CTAP),確保跨平台、瀏覽器與服務的一致安全性。裝置綁定的 Passkey 將私密金鑰儲存在硬體安全模組中,以提供最高等級的保證。同步式 Passkey 會在平台生態系中加密並同步金鑰,以提供更廣泛的可存取性。

了解 Passkey 與其所取代的密碼有何不同,能清楚看出安全性的提升。

Passkey 與網路安全的關聯

Passkey 在密碼學層級上阻止網路釣魚。當攻擊者對您的使用者發動網路釣魚活動時,透過 WebAuthn 通訊協定的來源綁定可防止在偽造網域上進行驗證。即使使用者點擊了釣魚連結並嘗試登入,該憑證也無法完成驗證流程,因為與合法網域的加密綁定會阻止它。

儲存在硬體安全模組中的私密金鑰無法透過軟體攻擊擷取。資料庫外洩無法暴露可重複使用的憑證,而憑證填充也會失敗,因為 Passkey 對每項服務都是唯一的。

真實世界事件顯示了這一點為何重要。2023 年 9 月,MGM Resorts 遭受一起社交工程攻擊,攻擊者冒充員工聯絡 IT 服務台,取得憑證後導致 勒索軟體 部署,估計造成 1 億美元損失。2022 年,一家主要身分識別供應商因第三方承包商遭入侵而發生憑證竊取事件,影響數百家客戶。

受 Passkey 保護的帳戶可消除憑證竊取作為初始存取方法,移除這些大多數資料外洩事件背後的 攻擊向量。這種防護的強度來自一組特定技術元件的協同運作。

Passkey 與密碼比較

密碼是共享秘密。您建立密碼、將其傳送至伺服器,而伺服器會儲存其雜湊副本。這條鏈中的每一步都可能遭受攻擊:使用者會選擇弱密碼、在不同服務間重複使用密碼,並受騙於即時蒐集密碼的釣魚頁面。即使是雜湊後的密碼資料庫也可能遭外洩並被離線破解。

Passkey 在每個層級上的運作方式都不同。您的裝置會產生一組加密金鑰配對,而私密金鑰永遠不會離開裝置。伺服器只儲存公開金鑰,若沒有對應的私密半部,這對攻擊者毫無用處。驗證透過已簽署的挑戰進行,因此沒有任何可重複使用的資訊會穿越網路。

實務上的差異相當顯著。密碼要求使用者記住複雜字串並定期更換,造成摩擦,進而導致重複使用與弱密碼選擇。Passkey 只需要生物特徵掃描或裝置 PIN 碼即可解鎖,無需記憶。密碼重設占 20-50% 的 IT 服務台來電;Passkey 可完全消除此類別。

從安全性的角度來看,密碼仍然容易受到網路釣魚、暴力破解攻擊、憑證填充與資料庫外洩的影響。Passkey 可抵禦這四者:

  • 網路釣魚 — 網域綁定可防止憑證在偽造網站上被使用
  • 暴力破解與憑證填充 — 不存在可供猜測或重放的密碼
  • 資料庫外洩 — 伺服器只儲存公開金鑰,若沒有私密半部便毫無用處
  • 憑證重複使用 — 每項服務的唯一性意味著一個帳戶遭入侵也無法解鎖其他帳戶

密碼提供的是單一驗證因素(您知道的東西),而 Passkey 結合了兩種:您擁有的東西(儲存私密金鑰的裝置)以及您本人的特徵(生物特徵驗證),在單一步驟中提供內建的 多因素驗證。

當 Passkey 面對真實世界的攻擊情境時,這些差異會直接轉化為可衡量的安全成果。

Passkey 的核心元件

Passkey 驗證依賴五項技術元件,以建立可抵禦網路釣魚的驗證:

  • 加密金鑰配對 構成基礎。每個 Passkey 都由在數學上相關聯的公開金鑰與私密金鑰組成。公開金鑰位於服務供應商的伺服器上;私密金鑰則保留在您使用者裝置上的硬體保護儲存區中。
  • 驗證器 會產生並儲存 Passkey。平台驗證器透過 TPM、Secure Enclaves 或 Trusted Execution Environments (TEEs) 整合至裝置中,使私密金鑰綁定於特定硬體。漫遊式驗證器包括 USB 安全金鑰與 Bluetooth 權杖。兩者都實作 CTAP 與 WebAuthn 規範,以提供網域綁定、抗網路釣魚能力,以及持有憑證的加密證明。
  • WebAuthn API 讓 Web 應用程式與瀏覽器能夠和驗證器互動。此 W3C 標準定義了註冊與驗證的執行方式,確保跨平台的一致性實作。
  • 依賴方 是指實作通行金鑰驗證的服務,負責產生挑戰、驗證回應,以及維護公開金鑰登錄資料。
  • 使用者驗證 確認合法使用者透過生物特徵驗證、裝置 PIN 或圖形解鎖來控制驗證器。驗證會在本機進行;生物特徵資料絕不會離開裝置。

這些元件透過兩個核心流程協同運作:註冊與驗證。

通行金鑰如何運作

這兩個流程都依賴加密挑戰回應機制,完全消除了憑證傳輸。

註冊流程

在註冊期間,依賴方會將需求傳送至使用者的瀏覽器,後者會呼叫 WebAuthn。驗證器會產生一組限定於該網域的唯一金鑰對。這種來源繫結可防止憑證重複使用與網路釣魚。

私密金鑰會儲存在受硬體保護的記憶體中。在裝置綁定的實作中,這表示硬體安全模組、TPM、Secure Enclaves 或安全金鑰晶片。在同步實作中,這表示無法匯出的加密雲端儲存。驗證器會將公開金鑰與憑證中繼資料回傳給依賴方。註冊可在數秒內完成,提供無需建立密碼的無密碼登入體驗。

驗證流程

當使用者進行驗證時,依賴方會產生隨機挑戰並連同憑證 ID 一起傳送。在使用者透過生物特徵掃描、輸入 PIN 或裝置解鎖完成驗證後,驗證器會使用私密金鑰對挑戰進行簽署。

已簽署的挑戰會回傳給依賴方進行驗證。若簽章相符,驗證即完成。挑戰會在數分鐘內過期,且無法重放。

跨裝置驗證情境

同步通行金鑰會在雲端鑰匙圈(iCloud Keychain 或 Google Password Manager)中加密私密金鑰,以便在相同生態系內跨多個裝置存取。它們提供便利的存取方式,但支援的證明功能有限,這表示組織無法始終以密碼學方式驗證所使用的確切安全硬體。裝置綁定通行金鑰則要求每次登入都必須使用實體驗證器,並透過完整的證明能力提供更高的保證,讓組織能夠驗證所涉及的確切安全金鑰型號或硬體安全模組。

對企業而言,在同步與裝置綁定憑證之間的選擇取決於風險承受度。高安全性環境,例如具特權的管理員帳戶,適合採用裝置綁定實作;而同步選項則適用於一般員工驗證,在便利性驅動採用的情況下效果良好。

在說明完運作機制後,下一個問題是通行金鑰能為您的組織帶來什麼。

通行金鑰的主要優勢

相較於以密碼為基礎的驗證,通行金鑰在安全性、營運與合規方面帶來四類可衡量的改善。

  1. 透過密碼學實現抗網路釣魚能力:使用 SMS 驗證碼的密碼式驗證仍容易受到即時網路釣魚攻擊,攻擊者會透過偽造網站代理請求。通行金鑰透過網域繫結消除此風險。WebAuthn API 會在驗證前驗證目的地網域,當網域不符時,流程將失敗。SMS 驗證碼、推播通知與 TOTP 仍容易受到中間人攻擊、SIM 卡交換與推播通知疲勞攻擊的影響。加密憑證則不會。
  2. 防止憑證竊取: 您的私密金鑰永遠不會離開使用者裝置。伺服器遭入侵也無法洩露可重複使用的憑證,因為伺服器僅儲存公開金鑰。即使具備核心層級存取權,資訊竊取惡意程式也無法從硬體安全模組中擷取金鑰。通行金鑰可因應攻擊者最常依賴的 憑證蒐集技術。
  3. 營運效率提升:部署通行金鑰可減少密碼重設請求,因為使用者不會忘記加密憑證。例如,USDA 的 FIDO 實作讓約 40,000 名使用者採用無密碼驗證,消除了一整類服務台工單。像 SentinelOne 的 Singularity Identity 這類身分安全平台,可在通行金鑰預防機制之外,對鎖定驗證基礎架構的憑證型威脅提供自主回應。
  4. 合規與保證等級一致性: 通行金鑰符合 NIST SP 800-63 AAL3 對抗網路釣魚多重要素驗證的要求。CISA 將 FIDO/WebAuthn 通行金鑰指定為 MFA 的黃金標準,因為它們提供網域繫結憑證,無法在偽造網站上使用。如前所述,絕大多數以憑證為基礎的資料外洩事件都涉及遭竊憑證,而通行金鑰可完全消除此類風險。

公開金鑰密碼學也提供密碼政策無法比擬、可供稽核的安全特性:針對特定網域驗證的密碼學證明、網路上零共享祕密,以及以硬體為根的金鑰產生。這些特性可在稽核期間提供可驗證的證據,並簡化包括 SOC 2、HIPAA 與 PCI DSS 在內各種框架的合規文件作業。

這些安全與營運優勢已推動各平台與各產業快速採用。

通行金鑰的平台支援與產業採用

Apple, Google,以及 Microsoft 都在其作業系統與瀏覽器中原生支援通行金鑰,讓組織能在大多數企業裝置環境中獲得跨平台涵蓋:

  • Apple 透過 iCloud Keychain 在 iOS、iPadOS 與 macOS 中整合通行金鑰
  • Google 透過 Android 與 Chrome 上的 Google Password Manager 提供支援
  • Microsoft 可透過 Windows Hello 和 Entra ID 啟用通行金鑰驗證

除了平台供應商之外,主要的消費者與企業服務也已採用通行金鑰登入。Amazon、PayPal、GitHub、Shopify 和 eBay 都支援使用通行金鑰進行客戶驗證。FIDO Alliance Passkey Directory 追蹤銀行、醫療保健與政府部門日益增加的採用情況。根據 FIDO Alliance 的資料,53% 的人已在至少一個帳戶上啟用通行金鑰。

對企業資安團隊而言,這項採用趨勢意味著無密碼驗證已不再是未來才需考慮的事項。包括 Microsoft Entra ID、Okta 和 Ping Identity 在內的身分識別提供者皆提供原生 FIDO2/WebAuthn 整合,使組織如今即可實際推動部署。

然而,日益增長的平台支援並未消除部署複雜性。

通行金鑰的挑戰與限制

企業通行金鑰部署面臨四項主要障礙,需要透過規劃與投資來解決。

  1. 舊有系統整合限制:無法與現代驗證服務整合的舊版應用程式,是部署上的主要障礙。許多組織因受限於舊有環境,而仰賴結合密碼與加密憑證的混合式系統,造成營運複雜性,因為您必須同時維護多個驗證基礎架構元件。大型主機應用程式、工業控制系統與嵌入式裝置,經常缺乏實作 WebAuthn 通訊協定所需的資源。您必須在維持以密碼驗證為主的孤島、投資驗證閘道,或接受某些系統將持續不受 passkey 涵蓋之間做出決策。及早規劃這些缺口,可避免在推行期間出現安全盲點。
  2. 跨平台實作不一致:儘管 WebAuthn 已標準化,各平台與瀏覽器之間的實作仍有所差異。同步通行金鑰僅能在單一平台生態系中運作:透過 iCloud Keychain 同步的私密金鑰無法從使用 Google Password Manager 的 Android 裝置存取,反之亦然。這些不一致會造成難以預測的驗證流程,進而使企業部署更加複雜。
  3. 帳戶復原複雜性: 裝置遺失或硬體故障會造成帳戶鎖定情境,因此需要健全的復原機制。使用者往往擔心失去存取權,而這種擔憂會成為採用上的心理障礙。將復原視為事後補救的組織,通常會看到更高的支援工單量與更低的採用率,因此在規劃期間,復原機制設計需要被視為首要考量。
  4. 組織變更管理: 使用者可能會抗拒不熟悉的驗證流程,尤其是在不了解其安全效益的情況下。支援人員在部署前需要接受有關疑難排解、復原程序及平台特定行為的訓練。UX、開發與產品團隊之間的跨職能協作,比起將通行金鑰視為純技術性計畫,更能有效解決採用障礙。

了解這些挑戰有助於您避免最常見的部署錯誤。

常見的通行金鑰實作錯誤

即使是規劃完善的通行金鑰推行,也可能在團隊忽略使用者體驗、錯誤處理與備援安全性時失敗。以下四種錯誤最為常見。

  • 在推行前略過使用者教育: 若在未處理使用者疑慮的情況下宣布部署,將導致混淆與抗拒。使用者會在缺乏背景脈絡的情況下遇到不熟悉的驗證提示,許多人因此會直接要求重設密碼或聯絡支援。教育內容應預先說明裝置遺失情境與復原程序,並提供適用於 iOS、Android 和 Windows 的平台特定工作流程。
  • 使用通用錯誤訊息: 顯示「Something went wrong」而非可執行指引的驗證流程,會削弱使用者信心。像是「This credential belongs to a different account」或「Your device policy requires an update」這類具體訊息,可引導使用者朝向解決方式前進,並在失敗情境中維持信任。
  • 復原測試不足:在未進行完整復原測試的情況下部署通行金鑰,會讓您的使用者暴露於帳戶鎖定風險。使用者可能在毫無預警下遺失裝置、備援驗證器發生故障,而雲端同步也可能發生中斷。請針對真實失敗情境測試復原程序,並提供逐步說明與視覺化指引。
  • 維持不安全的備援驗證:退回使用弱式單因子方法(僅電子郵件或 SMS OTP)的實作,仍會維持通行金鑰原本旨在阻止的相同攻擊弱點。請以多因子要求來設計備援機制,並刻意讓復原工作流程比主要驗證更不便利,以在保留緊急存取的同時,降低日常使用備援機制的可能性。

遵循經驗證的最佳實務有助於您避免這些陷阱,並建立具韌性的部署。

通行金鑰最佳實務

成功的企業部署在推行順序、使用者目標設定、復原設計與平台整合方面具有共同模式。

實施分階段推行策略

透過漸進式階段進行部署。首先,使用以應用程式為基礎的驗證器建立多因子驗證基準,在導入通行金鑰之前先建立組織能力。接著,導入通行金鑰並搭配抗網路釣魚 MFA 用於敏感應用程式,同時在過渡期間維持密碼備援。

隨著採用逐漸成熟,請將生命週期與復原流程正式化:

  • 遠端裝置解鎖與憑證簽發
  • 具備完整稽核軌跡以符合合規要求的撤銷程序
  • 跨組織的集中式憑證管理
  • 將基於密碼的驗證轉為僅限緊急備援使用

每個階段在進入下一階段前,都應包含明確的成功標準。

優先鎖定高風險使用者群組

優先部署給特權使用者、IT 管理員與高階主管。這些高價值目標面臨最高的憑證竊取風險,而 Verizon DBIR 顯示 57% 的社交工程事件涉及網路釣魚,而在所有資料外洩事件中,有 16% 是以網路釣魚作為初始存取方法。在較不敏感的服務之前,請先保護業務關鍵應用程式,包括電子郵件、VPN、HR 系統與財務工具。

建立健全的復原基礎架構

在不建立密碼後門的情況下實作多種復原機制。要求使用者在主要平台驗證器之外,一併註冊備援硬體安全金鑰,以確保遺失單一裝置不會導致完全鎖定。

管理性復原應透過多個管道驗證身分:照片證件審查、主管確認,以及安全性問題驗證。當使用者以相同平台帳戶登入替換裝置時,雲端同步通行金鑰可提供自動復原。對於需要硬體證明驗證的特權存取,請保留使用裝置綁定通行金鑰。

與身分識別平台整合

使用條件式存取原則,連接企業身分識別平台,包括 Microsoft Entra ID。以風險為基礎的驗證可在風險升高條件下強制執行抗網路釣魚的通行金鑰驗證,同時在低風險情境中允許更精簡的驗證。身分識別平台整合也可提供集中式稽核軌跡,將通行金鑰驗證與應用程式存取及使用者行為建立關聯。

建立持續改善流程

追蹤採用指標:註冊率、驗證成功率、復原頻率,以及服務台升級案件。隨著平台支援與組織成熟度演進,請根據營運資料與使用者回饋反覆調整驗證流程。

Passkey 可強化您的驗證邊界,但攻擊者不會止步於遭竊的憑證。

Callout Background Image Gradient

Reduce Identity Risk Across Your Organization

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

重點整理

Passkey 透過私密金鑰永不離開使用者裝置的密碼學驗證,消除憑證竊取與網路釣魚。沒有密碼會穿越網路,移除了攻擊者最常使用的初始存取方法利用。企業部署需要分階段推行,從高風險使用者與業務關鍵應用程式開始,並審慎規劃舊有系統限制、跨平台不一致性,以及使用者採用障礙。

若未妥善處理,略過使用者教育、使用通用錯誤訊息,以及維持薄弱的備援驗證,都可能削弱 Passkey 帶來的安全效益。身分安全平台可補強 Passkey 的預防能力,藉由找出鎖定憑證層之外驗證基礎架構的攻擊,包括 Active Directory 入侵、權限提升與橫向移動。

常見問題

Passkey 是一種無密碼的密碼學憑證,使用公開金鑰密碼學來取代密碼。您的裝置會產生一組唯一的金鑰對:私密金鑰會保留在您裝置上受硬體保護的儲存空間中,而公開金鑰則會提供給服務供應商。 

驗證是透過密碼學挑戰回應機制進行,因此密碼或可重複使用的祕密資訊都不會穿越網路。

不會。Passkey 使用非對稱密碼學,私密金鑰會保留在您裝置上的硬體安全模組中,且絕不會透過網路傳輸。 

網路釣魚嘗試會失敗,因為 Passkey 會在驗證前以密碼學方式驗證目的網域,防止其在偽造網站上被使用。

復原方式取決於您的架構。儲存在雲端金鑰圈中並經加密同步的 Passkey,仍可從任何已登入您平台帳戶的裝置存取。 

綁定裝置的 Passkey 需要在註冊期間登錄的備援驗證器。組織應實作多種復原機制,以防止帳戶被完全鎖定。

同步的 Passkey 可在相同平台生態系內的裝置間運作(Apple、Google、Microsoft)。跨平台驗證需要在每個生態系中分別註冊 Passkey,或使用實作 FIDO2 標準的硬體安全金鑰。

是。Passkey 符合 NIST SP 800-63B AAL3 對抗網路釣魚的多重要素驗證要求。具備硬體證明的綁定裝置 Passkey,可滿足聯邦系統最高等級的驗證保證要求。CISA 將 FIDO/WebAuthn Passkey 指定為 MFA 的黃金標準。

Passkey 實作了企業身分平台(包括 Microsoft Entra ID)所支援的 FIDO2/WebAuthn 標準。條件式存取原則會根據風險訊號強制執行以 Passkey 為基礎的驗證。 

實作需要分階段策略,以處理舊有系統相容性、復原機制與變更管理。

深入了解 身分安全

Decorative background gradient

準備好徹底革新您的安全營運了嗎?

了解 SentinelOne AI SIEM 如何將您的 SOC 轉型為自主化的強大中樞。立即聯絡我們以取得個人化示範,親眼見證安全防護的未來如何實現。
Dark dashboard UI with purple-highlighted nav, summary cards showing 149, 7, 78, 56, 1.2 h, and a status table with linked purple text