Password 與 Passkey：主要差異與安全性比較

什麼是 Password 和 Passkey？

設想這樣一個情境：凌晨 2:14，您的 SOC 分析師正在檢視驗證記錄，發現過去一小時內有數百次登入失敗嘗試。到了凌晨 2:31，其中一次使用先前資料外洩中遭竊的憑證成功登入，而您的安全堆疊從未將其標記出來。

這就是 Password 與 Passkey 之間的核心差異。Password 採用共享秘密模型，相同的憑證同時存在於您的裝置與伺服器上。當攻擊者入侵該伺服器或透過網路釣魚取得該憑證時，他們就擁有完成驗證所需的一切。Passkey 透過非對稱密碼學消除此弱點。私密金鑰永遠不會離開您的裝置，而儲存在伺服器上的公開金鑰對攻擊者而言在密碼學上毫無用處。

根據分析 22,052 起安全事件的 2025 DBIR，88% 的資料外洩涉及遭竊憑證。無論複雜度要求、輪替政策或使用者訓練為何，Password 都會造成系統性弱點。

Passkey 透過兩項互補標準實作 FIDO2 通訊協定架構：用於瀏覽器與平台憑證管理的 W3C Web Authentication (WebAuthn) 規範，以及用於應用程式與驗證器之間通訊的 FIDO Alliance CTAP2 (Client to Authenticator Protocol)。這些通訊協定共同以綁定特定網域的密碼學挑戰回應驗證，取代密碼傳輸。

當您註冊 Passkey 時，您的驗證器會為該特定帳戶產生一組唯一的公開／私密金鑰對。私密金鑰會保留在您裝置的硬體安全模組或安全隔區中，且絕不會透過網路傳輸。只有公開金鑰會向伺服器註冊。在驗證期間，伺服器會傳送一個密碼學挑戰，由您的裝置使用私密金鑰進行簽署，在不暴露金鑰本身的情況下證明持有權。

這些架構差異會直接決定哪些攻擊能成功，以及哪些攻擊會在您的基礎架構上失敗。

Password 和 Passkey 與網路安全的關聯

Passkey 可解決導致大多數資料外洩的驗證弱點。 NIST Special Publication 800-63B 要求 AAL2 採用抗網路釣魚驗證，並將其列為 AAL3 的強制要求，而 CISA CPG 2.0 也明確建議將 Passkey 作為抗網路釣魚的方法。無論長度、複雜度或輪替頻率如何，Password 都無法滿足任一要求。

資料突顯了原因。根據 2025 DBIR 研究，在攻擊高峰日，憑證填充攻擊占所有驗證流量的 44%，且 80% of compromised accounts 曾因其他服務而有先前的憑證外洩暴露。 Ransomware 出現在 44% 的資料外洩事件中，而密碼重複使用提供了初始存取點。2021 年 Colonial Pipeline 攻擊很好地說明了這一點；攻擊者使用單一遭入侵的 VPN 密碼取得網路存取權，根據 DOJ disclosures，導致支付 440 萬美元贖金。

Passkey 可消除這些攻擊路徑。根據 FIDO Alliance，Passkey 的設計使憑證能抵禦網路釣魚、憑證填充，以及大規模data breaches，因為儲存在伺服器上的公開金鑰若沒有使用者裝置上的私密金鑰，就不具任何驗證價值。

在詳細檢視特定攻擊向量之前，下表概述了 Password 與 Passkey 在安全團隊最重視的面向上的比較。

Password 與 Passkey 一覽

Password 與 Passkey 的差異涵蓋安全架構、使用者體驗、合規準備度與生態系支援。此比較根據 FIDO Alliance 研究、NIST 標準與 Verizon DBIR 資料，量化各個面向。

以下各節將深入探討這些面向，首先從 passkeys 旨在消除的特定密碼弱點開始。

安全弱點：密碼攻擊向量

密碼會造成四個主要弱點，直接影響您的安全態勢：易受網路釣魚攻擊、暴露於憑證填充攻擊、中間人攔截，以及資料庫遭入侵的影響。 NIST SP 800-63B 確認 FIDO2/WebAuthn 的非對稱密碼學架構可實現密碼無論複雜度要求為何都無法達成的抗網路釣魚驗證。

• 網路釣魚攻擊對基於密碼的驗證仍然有效。根據 2025 Verizon DBIR 所彙整的研究，即使在接受訓練課程後，使用者仍會點擊模擬網路釣魚演練。當使用者在攻擊者控制的網域上輸入密碼時，這些憑證會以明文形式傳送給對手，而對手會立即拿它們測試您的實際服務。2023 年 MGM Resorts 資料外洩事件很好地證明了這一點；攻擊者利用 social engineering 繞過 MFA，根據 SEC 文件，造成約 1 億美元的損失。
• 憑證填充會大規模利用密碼重複使用。 Verizon 的 2025 Data Breach Investigations Report 證實，80% 的遭入侵帳戶先前曾在其他服務中發生憑證暴露。使用者經常在消費者服務、專業平台和企業應用程式之間重複使用憑證。當任何消費者服務發生資料外洩時，攻擊者會立即拿這些憑證測試企業的 authentication endpoints。
• 中間人攻擊會攔截密碼傳輸。 MITM 攻擊者會將自己置於使用者與伺服器之間，利用偽造 SSL 憑證等技術攔截傳輸中的資料。基於密碼的驗證需要傳輸可證明身分的秘密，而這種傳輸無論傳輸加密如何都會造成弱點。
• 即使經過雜湊處理，資料外洩仍會暴露已儲存的密碼。 您的驗證資料庫包含的是密碼雜湊，而非明文密碼。這種保護會延緩憑證遭入侵，但無法防止。取得資料庫存取權的攻擊者會對雜湊密碼執行離線暴力破解攻擊，而不會觸發帳戶鎖定原則或速率限制。當您的資料庫遭入侵時，整個使用者群體中的每個密碼都需要立即重設。

Passkeys 透過使憑證竊取失效的密碼學架構消除這些弱點。

Passkey 密碼學架構

Passkeys 提供的安全保證取決於底層密碼學的運作方式。不同於依賴共用值保密性的密碼，passkeys 使用公開金鑰密碼學，其中驗證證明與驗證秘密在本質上是不同的物件。

在驗證期間，您的伺服器會透過 WebAuthn API 將密碼學挑戰傳送至使用者的驗證器。驗證器使用儲存在裝置上的私密金鑰對此挑戰進行簽署，而簽署後的聲明會透過瀏覽器返回您的伺服器。您的伺服器使用先前註冊的公開金鑰驗證數位簽章。此挑戰回應流程可證明使用者持有私密金鑰，而無需將其暴露。

網域繫結提供抗網路釣魚能力。 WebAuthn 會以密碼學方式將驗證繫結至發生註冊的特定來源網域。當使用者造訪模仿您網域的 phishing 網站時，瀏覽器的 WebAuthn 實作會阻止驗證回應傳送至錯誤的來源。此保護是在通訊協定層級運作，而非依賴使用者判斷。即使使用者完全被視覺相似性所欺騙，網路釣魚網站也無法接收您網域的有效驗證回應。

這些密碼學演算法符合政府與企業部署的 NIST 規範。支援的演算法包括：

• 用於簽章作業的 ECDSA、RSA 和 EdDSA 變體
• 用於雜湊的 FIPS 202 (SHA-3)
• 用於金鑰衍生的 SP 800-108
• 用於隨機數產生的 SP 800-90a

這些定義於 FIDO Authenticator Allowed 密碼學 清單，其中明確引用了 NIST 標準。建立於此架構上的可探索憑證可實現無密碼驗證，讓使用者無需記住使用者名稱，而瀏覽器自動填入整合則可簡化登入體驗。

這個密碼學基礎轉化為密碼與通行金鑰在日常使用感受上的實際差異。

使用者體驗：密碼 vs 通行金鑰登入

密碼驗證要求使用者為每項服務記住唯一憑證、正確輸入，並完成額外的 MFA 步驟，例如輸入 SMS 驗證碼或核准推播通知。這種多步驟流程會產生可衡量的摩擦。根據 FIDO Alliance Passkey Index，以密碼為基礎的登入平均成功率為 63%，這表示超過三分之一的嘗試會因忘記憑證、輸入錯誤或 MFA 權杖過期而失敗。

通行金鑰驗證將登入簡化為單一步驟。使用者透過生物辨識（Face ID、指紋或 Windows Hello）或裝置 PIN 進行驗證。 FIDO Alliance World Passkey Day research 發現，通行金鑰可達到 93% 的登入成功率，且平均每次登入耗時 13.6 秒，相較於密碼的 27.5 秒更快。無需記憶、無需輸入，也無從攔截。生物辨識資料會保留在裝置上，絕不傳送至伺服器，同時維護安全性與隱私。

對組織而言，這項 UX 改善會直接轉化為營運節省。FIDO Alliance Passkey Index 參與者回報，在部署通行金鑰後，與登入相關的服務台來電減少了 81%，消除了 IT 支援中最大的一項持續性成本。

這些 UX 優勢取決於您的使用者與應用程式實際執行的位置，因此平台與生態系統的就緒程度成為關注重點。

平台與生態系統支援

主要平台上的通行金鑰支援已廣泛可用：

• Apple 透過 iCloud Keychain 在 iOS、iPadOS 與 macOS 裝置間以端對端加密同步通行金鑰。
• Google 透過 Android 9+ 和 Chrome 上的 Google Password Manager 管理通行金鑰，並在登入相同 Google 帳戶的所有裝置間同步。
• Microsoft 透過 Windows 10+ 上的 Windows Hello 整合通行金鑰，並支援 Edge 與 Microsoft 帳戶。

根據 FIDO Alliance，全球前 100 大網站中已有 48% 支援通行金鑰驗證，數量是 2022 年的兩倍以上。

跨平台驗證可透過 QR code 交接與 Bluetooth 近距離運作，讓使用者能使用儲存在手機上的通行金鑰在筆記型電腦上完成驗證。包括 1Password 與 Bitwarden 在內的第三方密碼管理器現在也支援通行金鑰儲存與同步，降低對單一生態系統的依賴。FIDO Alliance 的 Credential Exchange Protocol (CXP) 也正在成熟，以支援供應商之間的安全通行金鑰轉移，解決供應商鎖定疑慮。

瀏覽器支援相當完整。Safari、Chrome、Edge 與 Firefox 都已實作通行金鑰驗證所需的 WebAuthn API。這表示您的 web applications 無需瀏覽器特定程式碼即可支援通行金鑰。

儘管有這麼廣泛的平台支援，通行金鑰仍引入了組織在承諾推行前需要規劃的取捨。

通行金鑰的限制與取捨

沒有任何驗證技術是毫無摩擦的，而理解這些限制有助於您建立切實可行的部署策略。

1. 生態系統依賴性仍然是一項疑慮。同步的通行金鑰目前仍綁定於特定平台的憑證管理器。使用 Apple iCloud Keychain 的員工無法直接從 Android 裝置存取這些通行金鑰。雖然 QR code 驗證與第三方密碼管理器提供了替代方案，但跨生態系統可攜性仍在發展中。FIDO Alliance 的 Credential Exchange Protocol 旨在解決此問題，但完整互通性尚未成為標準。
2. 共用帳戶與服務帳戶會帶來複雜性。通行金鑰會綁定至個別裝置與生物辨識，因此難以用於共用團隊帳戶、服務帳戶或多位使用者在同一裝置上驗證的 kiosk 終端。組織通常會透過為共用帳戶維持以密碼為基礎的驗證，同時為個別使用者存取部署通行金鑰來解決此問題。
3. 沒有密碼的復原需要新的工作流程。當使用者遺失所有裝置且未註冊任何備援驗證器時，帳戶復原會比單純重設密碼更複雜。組織需要經過充分測試的復原程序，包括管理員協助復原與帶外身分驗證。
4. 並非所有服務都已支援通行金鑰。 儘管採用率持續成長，許多舊版應用程式、內部工具與第三方 SaaS 產品仍缺乏 WebAuthn 支援。在遷移期間，您的組織很可能會維持混合式驗證，由通行金鑰保護主要身分提供者，而密碼則持續用於未受支援的系統。

這些限制形塑了企業在實務上如何推動通行金鑰部署，而資料顯示，儘管存在複雜性，多數企業仍持續向前推進。

企業密碼 vs 通行金鑰部署

根據 FIDO Alliance Enterprise Deployment Survey，該調查涵蓋來自英國與美國、員工數超過 500 人公司的 400 位高階主管，其中 87% 的組織已部署或正在積極實作員工登入的通行金鑰驗證。許多組織採取分階段方法，在全面推行前先處理基礎架構整合。組織記錄到在實作通行金鑰後，密碼使用量減少了 26%，顯示部分採用也能在處理舊系統相容性問題的同時，帶來可衡量的安全性改善。

您的身分平台需要支援 WebAuthn API 與通行金鑰生命週期管理能力。大多數現代身分提供者現在都透過 WebAuthn 支援通行金鑰驗證。整合發生在您的 Identity Provider (IdP) 層，使用者先使用通行金鑰完成驗證，之後才會向聯盟應用程式簽發 SAML 聲明或 OIDC 權杖。像 SentinelOne Singularity Platform 這類安全平台應與您的 IdP 整合，以維持對驗證事件的可視性，將以通行金鑰為基礎的登入與端點活動及使用者行為分析建立關聯。

您的 Mobile Device Management (MDM) 和 統一端點管理 (UEM) 原則也需要更新，以支援通行金鑰驗證器和裝置證明。舊版應用程式相容性是主要的部署障礙。您需要完整的應用程式清冊，以對應哪些系統支援通行金鑰，以及哪些系統在遷移期間需要閘道解決方案或持續使用密碼驗證。

使用者採用情況會影響安全成果。這份 Thales/FIDO Alliance State of Passkey Deployment Report 2024 年報告指出，使用者教育是主要的部署挑戰之一。報告記錄了使用者對通行金鑰概念的困惑，尤其是跨裝置同步，以及對改變既有習慣的抗拒。未能推動採用的組織，即使在實作通行金鑰後，仍有可能維持相同的弱點與成本。

除了營運部署之外，通行金鑰的採用還必須滿足規範框架與 Zero Trust 架構，這些框架與架構主導企業的安全態勢。

法規遵循與 Zero Trust 對齊

通行金鑰可滿足密碼無法達成的抗網路釣魚驗證要求。 NIST Special Publication 800-63B 定義了驗證保證等級，其中 AAL2 明確要求提供抗網路釣魚選項，而 AAL3 則要求專門使用這些選項。如果您僅使用密碼，無論複雜度原則或多重要素驗證層級為何，都無法滿足這些要求。

對於聯邦企業部署，NIST 補充指引確認同步通行金鑰符合 AAL2 要求。聯邦驗證金鑰必須儲存在已達成 Federal Information Security Modernization Act (FISMA) 合規的同步架構中。PCI Security Standards Council 也已發布 FAQ 1595 與 FAQ 1596，專門說明通行金鑰與以 FIDO2 為基礎的驗證如何符合支付卡產業法規遵循要求。

通行金鑰符合核心 Zero Trust 原則：

• 私密金鑰永遠不會離開驗證器裝置，可防止認證資料遭竊與重放攻擊。
• 驗證會以密碼編譯方式繫結至已驗證的網域，透過驗證依賴方來阻止網路釣魚。
• 每個工作階段都需要裝置持有權的密碼編譯證明，而不是提交快取的認證資料。

綜合而言，這些特性支援 Zero Trust「永不信任，一律驗證」的要求。

對於位於 GDPR 司法管轄區、醫療保健 或 SOC 2 合規 環境中的組織而言，通行金鑰可透過降低個人資料曝露，以及提供符合 NIST AAL2/AAL3 標準的抗網路釣魚驗證來支援法規遵循。滿足這些要求只是其中一半；另一半是在您轉換期間維持整個驗證基礎架構的可視性。

Singularity™ Identity

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

Get a Demo

重點整理

密碼透過共享祕密造成系統性弱點，攻擊者會利用網路釣魚、憑證填充和資料外洩來竊取這些祕密。通行金鑰透過非對稱 密碼編譯 消除這些攻擊，其中私密金鑰永遠不會離開使用者裝置。 

由於 88% 的外洩事件 涉及遭竊認證資料，且87% 的美國/英國企業（員工數超過 500 人）正在部署或實作通行金鑰，因此方向已十分明確。NIST 與 CISA 明確要求採用抗網路釣魚驗證，而密碼無論複雜度原則為何都無法提供這種能力。