通过密钥凭证：无密码认证中一个新颖的攻击面

认证领域正在经历一场剧烈变革，正从传统的用户名和密码模式转向更无缝、无密码的认证方式。FIDO2/WebAuthn等技术和生物识别技术承诺，登录账户将像指纹扫描或查看智能手机一样简单。然而，随着我们拥抱这些进步，我们也必须面对新的漏洞。Palo Alto Networks的Unit42团队最近的一项分析（在Hacker News上讨论过）揭示了这个无密码生态系统中出现的一个新颖攻击面：攻击者可能“通过密钥凭证”。

无密码认证的魅力

无密码认证方法提供了引人入胜的优势：

提升可用性：无需记住复杂密码或管理密码重置，显著提升了用户体验。
增强安全性：传统密码在钓鱼攻击、暴力破解攻击和凭证填充攻击中臭名昭著。无密码方法，特别是利用公钥密码学（FIDO2/WebAuthn）的方法，通过无需存储密码，提供了一种更强、更安全的替代方案。
减少摩擦：精简的登录流程可以提高用户参与度，降低服务的流失率。

其核心原理是，FIDO2/WebAuthn用存储在设备（如智能手机或专用安全密钥）上的加密密钥取代密码，并由服务提供商管理。当用户尝试登录时，浏览器或应用程序使用这些密钥启动挑战-响应机制，在不泄露密码的情况下证明身份。

介绍“通过密钥凭证”攻击

“通过密钥凭证”攻击的核心概念围绕着攻击者拦截或操纵认证过程的可能性，从而在不攻破密钥凭证本身的情况下，有效地冒充用户身份。这不是关于窃取密码；而是利用被盗会话令牌、拦截的挑战-响应数据或其他与已建立会话相关的手段，绕过认证机制。

分析指出，这种攻击可能出现在以下几个潜在的攻击向量：

拦截会话令牌：如果攻击者能够拦截成功无密码登录后颁发的会话令牌，他们可能会利用它来获得未经授权的访问权限。这在原则上类似于会话劫持，但专门针对无密码认证的上下文。
挑战-响应的中间人（MitM）攻击：虽然FIDO2/WebAuthn通信通常通过TLS进行保护，但攻击者可能拦截服务器在认证流程中发送的初始挑战。如果服务器随后依赖接收这个特定挑战作为验证过程的一部分，并且没有进行充分的检查，攻击者可能能够使用之前捕获或修改的挑战来构建响应，欺骗服务器接受认证。
利用会话管理漏洞：与基于密码的会话一样，与密钥凭证相关联的会话管理和验证也可能存在漏洞。如果攻击者能够操纵服务器端的会话状态变量，他们可能能够获得访问权限。

这里的关键区别在于上下文。密码攻击针对凭证（密码）。“通过密钥凭证”攻击针对用于在密钥凭证似乎已通过验证后建立信任的会话或机制。

为何这是一个关注点？

无密码认证旨在取代密码的弱点。如果攻击者能够成功“通过密钥凭证”，这将破坏这一目标。它为攻击者提供了一种新的方式，让他们无需破解复杂密码或窃取凭证就能获得未经授权的访问。这可能导致：

数据泄露：攻击者获得对用户账户的访问权限，可能窃取敏感个人信息。
账户劫持：用户失去对其账户的控制，可能导致经济损失或身份盗窃。
信任受损：如果此类漏洞被利用，用户可能会对无密码技术失去信心。

分析漏洞环境

Unit42分析（在Hacker News上讨论过）是一个警钟。它表明，无密码认证的安全性不仅仅取决于加密密钥的强度或生物识别传感器的可用性。它也与周围基础设施的安全性密切相关，特别是会话管理和通信协议。

考虑使用密钥凭证登录网站时的典型流程：

用户发起登录。
服务器生成挑战并发送到客户端。
客户端使用密钥凭证对挑战进行签名。
客户端将签名的挑战发送回服务器。
服务器使用用户的注册公钥验证签名。
服务器在成功验证后颁发会话令牌。
客户端使用此令牌进行后续请求。

“通过密钥凭证”攻击可能发生在第5步、第6步，或涉及在第2步和第3步之间交换/验证的数据。漏洞通常不在于FIDO2/WebAuthn协议本身（该协议通常能抵御被动窃听），而在于应用程序如何集成和管理认证结果和会话。

例如，如果应用程序通过不安全的信道盲目信任接收到的会话令牌，或者在不进行适当验证的情况下重用挑战-响应机制，攻击者可以拦截初始响应（第3步）并在稍后重放它以获得访问权限（实际上是在“传递”认证结果）。

理解风险背景

必须明确的是，“通过密钥凭证”不一定是FIDO2/WebAuthn本身的基本缺陷。FIDO2旨在防止在密钥建立阶段发生被动窃听和中间人攻击。风险源于实现FIDO2的服务如何与其交互以及管理后续会话。

可以这样理解：FIDO2提供了一种安全的方式来证明你知道你的秘密密钥（第3步）。然而，应用程序仍需信任这种证明（第5步）并管理由此产生的访问权限（第6步）。如果应用程序的会话管理存在缺陷，安全的证明就可能被误用。

缓解策略：在无密码基础上安全构建

解决“通过密钥凭证”漏洞需要一个全面的方法，重点在于安全的应用程序设计和强大的会话管理：

安全的传输层：确保所有通信，尤其是在认证流程（第2-4步）中，都通过HTTPS/TLS进行，以防止中间人攻击和数据拦截。
无状态会话管理：设计服务器端的会话管理尽可能无状态。避免仅依赖可能被拦截和重放的客户端会话标识符。考虑使用短生命周期的会话令牌，并结合强大的客户端验证技术。
强令牌验证：在颁发会话令牌（第6步）时，确保令牌是强的，具有短的有效期，并结合难以被攻击者预测或复制的用户特定或设备特定标识符。
服务器端重新认证：对于敏感操作或在非活动 periods 后，可以考虑为使用密钥凭证登录的用户实施服务器端重新认证机制。这为会话劫持增加了一层额外的防御。
定期安全审计：彻底审计无密码认证的实现，不仅要关注FIDO2集成，还要关注会话管理、令牌处理和整体应用程序安全。
教育用户和开发者：用户应意识到即使无密码登录也不是免疫风险的，特别是试图诱骗他们泄露密钥凭证凭证（如生物识别或设备代码）的钓鱼攻击。开发者必须接受无密码流程的安全编码实践培训。

代码片段：一个假设性的漏洞

让我们考虑一个简化的、假设性的服务器端伪代码片段，说明一个潜在的漏洞：

# 伪代码说明一个潜在的漏洞

# 第1步：用户通过HTTPS发送回签名的挑战（响应）
response = receive_response_from_client()

# 第2步：服务器使用注册的公钥验证签名
if verify_signature(response, user_public_key):
    # 潜在漏洞：在未检查上下文的情况下盲目信任响应
    issue_session_token(response) # <--- 不安全：如果响应被拦截，令牌可能被重放
    grant_access_to_user()
else:
    deny_access()

在这个有缺陷的示例中，如果 response（包含签名的挑战）被拦截（一个中间人攻击），攻击者可以在稍后重放这个 response 给服务器，可能因为服务器盲目信任任何有效的签名而没有进行额外的上下文检查而获得访问权限。

更安全的方法包括：

# 伪代码说明一个更安全的方法

# 第1步：用户通过HTTPS发送回签名的挑战（响应）
response = receive_response_from_client()

# 第2步：服务器使用注册的公钥验证签名
if verify_signature(response, user_public_key):
    # 安全检查：验证响应是否包含新鲜的、不可重放的nonce/令牌
    # 这个nonce/令牌可以与特定的认证会话或用户上下文相关联
    if check_nonce_and_context(response, current_session_context):
        issue_secure_session_token(response) # <--- 更安全：需要新鲜上下文
        grant_access_to_user()
    else:
        log_suspicious_activity(response)
        deny_access()
else:
    deny_access()

关键的增加是 check_nonce_and_context 步骤，这使得重放拦截的响应变得非常困难或不可能。

前进之路：平衡安全与便利

无密码认证代表了在可用性和安全性方面的一大步。然而，它并非万能药。“通过密钥凭证”作为一个潜在的攻击向量出现，突显了安全实现的重要性。整个认证生态系统的安全性不仅依赖于各个组件（密钥、协议、生物识别）的强度，还依赖于从初始挑战到持续会话管理的整个用户旅程的精心设计和安全管理。

随着我们构建和采用这些新技术，一种积极主动和安全意识的心态至关重要。开发人员必须在无密码方法提供的便利性与安全会话管理和应用程序设计优先级之间取得平衡。用户也应保持警惕，防范针对最安全认证机制的钓鱼攻击。

总结

“通过密钥凭证”漏洞突显了向无密码认证过渡时引入了新的攻击面。虽然FIDO2/WebAuthn为安全密钥建立提供了坚实的基础，但整体认证过程的安全性严重依赖于服务如何实现会话管理、令牌处理和通信安全。解决这些实施差距对于实现无密码技术的全部潜力同时保持强大的安全防御至关重要。它提醒我们，安全是一个持续的过程，随着新技术的出现，需要持续的警惕和改进。

Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

The landscape of authentication is undergoing a seismic shift, moving away from the traditional username and password paradigm towards more seamless, passwordless methods. Technologies like FIDO2/WebAuthn and biometrics promise a future where logging into our accounts is as simple as a fingerprint scan or a glance at our smartphone. However, as we embrace these advancements, we must also confront new vulnerabilities. A recent analysis by Palo Alto Networks' Unit42 team, discussed on Hacker News, highlights a novel attack surface emerging within this passwordless ecosystem: the potential for attackers to "pass the passkey."

The Allure of Passwordless Authentication

Passwordless authentication methods offer compelling advantages:

Improved Usability: Eliminating the need to remember complex passwords or manage password resets significantly enhances the user experience.
Increased Security: Traditional passwords are notoriously vulnerable to phishing, brute-force attacks, and credential stuffing. Passwordless methods, particularly those leveraging public key cryptography (FIDO2/WebAuthn), offer a stronger, more secure alternative by eliminating the need to store passwords.
Reduced Friction: Streamlined login processes can lead to higher user engagement and lower churn rates for services.

At its core, FIDO2/WebAuthn replaces passwords with cryptographic keys stored on devices (like smartphones or dedicated security keys) and managed by the service provider. When a user attempts to log in, the browser or application initiates a challenge-response mechanism using these keys, proving identity without revealing a password.

Introducing the "Pass the Passkey" Attack

The core concept of "passing the passkey" revolves around the potential for an attacker to intercept or manipulate the authentication process, effectively assuming the user's identity without needing to compromise the passkey itself. This isn't about stealing a password; it's about bypassing the authentication mechanism using stolen session tokens, intercepted challenge-response data, or other means related to the established session.

The analysis points to several potential vectors where this attack could manifest:

Intercepted Session Tokens: If an attacker can intercept the session token issued after a successful passwordless login, they might be able to reuse it to gain unauthorized access. This is similar in principle to session hijacking, but specifically targeting the context of passwordless authentication.
Man-in-the-Middle (MitM) Attacks on Challenge-Response: While FIDO2/WebAuthn communication is often secured via TLS, an attacker could potentially intercept the initial challenge sent by the server during the authentication flow. If the server then relies on receiving this specific challenge back as part of the verification process without sufficient checks, the attacker could potentially craft a response using a previously captured or modified challenge to fool the server into accepting the authentication.
Exploiting Flaws in Session Management: Just like password-based sessions, the management and validation of sessions associated with passkeys can contain vulnerabilities. If an attacker can manipulate these session state variables on the server side, they could potentially gain access.

The critical difference here is the context. Password attacks target the credential (the password). "Pass the passkey" attacks target the session or the mechanism used to establish trust after the credential has seemingly been validated by the passkey.

Why is this a Concern?

Passwordless authentication aims to replace the weaknesses of passwords. If an attacker can successfully "pass the passkey," it undermines this very goal. It introduces a new way for attackers to gain unauthorized access without needing to crack a complex password or steal a credential. This could lead to:

Data Breaches: Attackers gaining access to user accounts can steal sensitive personal information.
Account Takeovers: Users losing control of their accounts, potentially leading to financial loss or identity theft.
Compromised Trust: Users may lose faith in passwordless technologies if such vulnerabilities are exploited.

Analyzing the Vulnerability Landscape

The Unit42 analysis, as discussed on Hacker News, serves as a wake-up call. It suggests that the security of passwordless authentication isn't just about the strength of the cryptographic keys or the usability of the biometric sensors. It's also deeply intertwined with the security of the surrounding infrastructure, particularly the session management and communication protocols.

Consider the typical flow when using a passkey for a website:

User initiates login.
Server generates a challenge and sends it to the client.
Client uses the passkey to sign the challenge.
Client sends the signed challenge back to the server.
Server verifies the signature using the user's registered public key.
Server issues a session token upon successful verification.
Client uses this token for subsequent requests.

A "pass the passkey" attack could potentially occur at steps 5, 6, or involve intercepting/validating the data exchanged between steps 2 and 3. The vulnerability often lies not in the core FIDO2/WebAuthn protocol itself (which is generally robust against passive eavesdropping), but in how the application integrates and manages the authentication result and session.

For example, if an application blindly trusts a session token received via an insecure channel, or if it reuses a challenge-response mechanism without proper validation, an attacker could intercept the initial response (step 3) and replay it later to gain access (effectively "passing" the authentication result).

Contextualizing the Risk

It's crucial to understand that "pass the passkey" isn't necessarily a fundamental flaw in FIDO2/WebAuthn itself. FIDO2 is designed to be secure against passive eavesdropping and man-in-the-middle attacks during the key establishment phase. The risk arises from how the service implementing FIDO2 interacts with it and manages the subsequent session.

Think of it like this: FIDO2 provides a secure way to prove you know your secret key (step 3). However, the application still needs to trust that proof (step 5) and manage the resulting access (step 6). If the application's session management is flawed, the secure proof can be misused.

Mitigation Strategies: Building Securely on Passwordless Foundations

Addressing the "pass the passkey" vulnerability requires a holistic approach focusing on secure application design and robust session management:

Secure Transport Layer: Ensure all communication, especially during the authentication flow (steps 2-4), occurs over HTTPS/TLS to prevent MitM attacks and data interception.
Stateless Session Management: Design session management to be as stateless as possible on the server side. Avoid relying solely on server-side session identifiers that could be intercepted and replayed. Consider using techniques like short-lived session tokens combined with strong client-side validation.
Strong Token Validation: When issuing session tokens (step 6), ensure they are strong, have a short expiration, and incorporate user-specific or device-specific identifiers that are difficult for an attacker to predict or replicate.
Server-Side Re-authentication: For sensitive operations or after periods of inactivity, consider implementing server-side re-authentication mechanisms, even for users logged in via passkeys. This adds an extra layer of defense against session hijacking.
Regular Security Audits: Thoroughly audit the implementation of passwordless authentication, focusing not just on the FIDO2 integration but also on session management, token handling, and overall application security.
Educate Users and Developers: Users should be aware that even passwordless logins aren't immune to risk, particularly phishing attacks that try to trick them into revealing their passkey credential (like biometrics or device codes). Developers must be trained in secure coding practices for passwordless flows.

Code Snippet: A Hypothetical Vulnerability

Let's consider a simplified, hypothetical server-side snippet in pseudo-code that illustrates a potential vulnerability:

# Pseudo-code illustrating a potential vulnerability

# Step 1: User sends signed challenge back (response) over HTTPS
response = receive_response_from_client()

# Step 2: Server verifies signature against registered public key
if verify_signature(response, user_public_key):
    # Potential Vulnerability: Blindly trusting the response without checking context
    issue_session_token(response) # <--- INSECURE: Token could be replayed if response intercepted
    grant_access_to_user()
else:
    deny_access()

In this flawed example, if the response (containing the signed challenge) is intercepted (a MitM attack), an attacker could later replay this response to the server, potentially gaining access because the server blindly trusts any valid signature without additional context checks.

A more secure approach would involve:

# Pseudo-code illustrating a more secure approach

# Step 1: User sends signed challenge back (response) over HTTPS
response = receive_response_from_client()

# Step 2: Server verifies signature against registered public key
if verify_signature(response, user_public_key):
    # Secure Check: Verify response contains a fresh, non-replayable nonce/token
    # This nonce/token could be tied to the specific authentication session or user context
    if check_nonce_and_context(response, current_session_context):
        issue_secure_session_token(response) # <--- More secure: Requires fresh context
        grant_access_to_user()
    else:
        log_suspicious_activity(response)
        deny_access()
else:
    deny_access()

The key addition is the check_nonce_and_context step, which makes replaying the intercepted response much harder or impossible.

The Path Forward: Security and Convenience in Balance

Passwordless authentication represents a significant step forward in usability and security. However, it's not a silver bullet. The emergence of "pass the passkey" as a potential attack vector underscores the importance of secure implementation. The security of the entire authentication ecosystem relies not just on the strength of the individual components (keys, protocols, biometrics) but on the careful design and secure management of the entire user journey, from initial challenge to ongoing session.

As we build and adopt these new technologies, a proactive and security-conscious mindset is essential. Developers must prioritize secure session management and application design alongside the convenience offered by passwordless methods. Users, too, should remain vigilant against phishing attempts that target even the most secure authentication mechanisms.

Takeaway

The "pass the passkey" vulnerability highlights that the transition to passwordless authentication introduces new attack surfaces. While FIDO2/WebAuthn provides a robust foundation for secure key establishment, the security of the overall authentication process depends critically on how services implement session management, token handling, and communication security. Addressing these implementation gaps is crucial to realizing the full potential of passwordless technology while maintaining strong security defenses. It serves as a reminder that security is an ongoing process, requiring constant vigilance and improvement as new technologies emerge.

通过 Passkey：无密码认证中的新型攻击面