Can Passkeys Be Exploited for Account Access?
好的,我现在需要帮用户总结这篇文章的内容。用户的要求是用中文,控制在100字以内,不需要特定的开头,直接描述文章内容。 首先,我得通读整篇文章,理解其主要观点。文章讨论了无密码认证(passkeys)的安全性,指出虽然它们使用FIDO2和公钥加密技术来防止钓鱼攻击,但并非绝对安全。文中提到实现漏洞、管理错误、会话劫持、社会工程学攻击以及设备丢失等问题都可能被利用。此外,文章还强调了开发者在后端逻辑中的重要性,并指出尽管存在缺陷,passkeys仍然是当前最佳的安全方案。 接下来,我需要将这些要点浓缩到100字以内。重点包括:passkeys的安全机制、存在的漏洞类型、会话劫持的风险、社会工程学的影响以及开发者的责任和解决方案。 然后,我要确保语言简洁明了,避免使用复杂的术语或结构。同时,要涵盖文章的主要论点:passkeys的优势、潜在风险以及建议的防范措施。 最后,检查字数是否符合要求,并确保总结准确传达原文的核心内容。 </think> 无密码认证(passkeys)通过FIDO2和公钥加密技术防止钓鱼攻击,但存在实现漏洞、管理错误及会话劫持风险。社会工程学攻击和设备丢失也威胁其安全性。开发者需严格验证后端逻辑以提升安全性。尽管有缺陷,passkeys仍是当前最佳安全方案。 2026-1-26 00:2:23 Author: securityboulevard.com(查看原文) 阅读量:5 收藏

The myth of the unhackable passkey

Everyone thinks passkeys are the "unhackable" endgame for auth. They use fido2 and public key cryptography to kill phishing by design, which sounds perfect on paper.

  • Cryptographic backing: No shared secrets for hackers to steal.
  • Phishing resistance: The browser is designed to only sign challenges for the domain that created the credential, preventing users from accidentally providing access to a fake site.
  • Biometric ease: Users love touchID over passwords. (Why would anyone still prefer Touch ID over simply glancing … – Quora)

Diagram 1: The standard Passkey Registration flow where a user creates a new public/private key pair.

But even "perfect" systems have implementation flaws. A recent Reddit thread discussing CVE-2024-9956 shows how subtle bugs in credential management can still lead to account takeovers. In this bitwarden case, a flaw in how the browser extension handled passkey requests could allow a malicious site to trick the vault into releasing the wrong credential.

Nothing's ever 100% safe. Let's look at how things actually break.

Technical ways passkeys can actually be exploited

So you think passkeys are bulletproof because there's no password to phish? i wish that was true but the reality is more messy. Even with fido2, the software handling your keys can have massive holes.

A passkey is only as secure as the vault it lives in. If the manager has a logic error, an attacker might swap your public key for theirs without you ever knowing.

  • Improper validation: If an api doesn't strictly check the origin during registration, an attacker could inject their own credential into your account.
  • Vault sync issues: As previously discussed regarding the bitwarden cve—where the extension didn't properly isolate requests—bugs in how passkeys are handled by the provider can lead to full account takeover.
  • Broken session management: Even if the login is secure, if the backend doesn't tie the passkey to a specific session correctly, it's game over.

Diagram 2: The Authentication flow showing how a server verifies a signed challenge from the user.

Then there's the "hands-on" problem. If someone grabs your unlocked phone while you're distracted in a coffee shop, they own your digital life.

  • Stolen devices: Many systems fall back to a simple PIN if biometrics fail, which is easily shoulder-surfed in retail or transit settings. (PIN or biometrics, which is most secure? – nextAuth)
  • Older sensors: some older android or laptop hardware can be fooled by high-res photos or 3d prints, though it's getting harder.

Next, we'll dive into why session cookies are still the real prize for attackers, even after a secure login.

Why session hijacking is still the real prize

Even if you have the most secure passkey login in the world, it only protects the "front door." Once a user is logged in, the server gives them a session cookie or a token. This is where the real danger lives today.

If an attacker can steal that session cookie—through malware on your laptop or a cross-site scripting (XSS) attack—they don't need your passkey. They just "become" you in the eyes of the server. This is called session hijacking, and it's how most big hacks happen now. Passkeys make it harder to get in, but they don't do anything to protect the session once it's started.

Next up, we're looking at how social engineering still works in a passwordless world.

Social engineering in a passwordless world

Think passkeys stop phishing? technically yes, but humans are still the weakest link in the chain. Attackers just shifted from stealing passwords to tricking you into "registering" their hardware to your account.

  • Account recovery traps: Hackers pose as support, convincing users to add a "backup" device—which is actually the attacker's key.
  • Malicious onboarding: In finance or retail, a user might get a fake "security upgrade" prompt that actually registers a silent fido2 credential for the hacker.
  • CIAM flow gaps: Many Customer Identity and Access Management (CIAM) systems have weak verification during the "add new device" phase, making it easy to bypass MFA if the initial session is hijacked.

MojoAuth handles these workflows way better by enforcing strict identity verification before any new keys get added, so you don't have to build that logic from scratch.

The developer's role in preventing exploits

So, you've integrated fido2 and think the job's done. honestly, that's where most devs mess up. Passkeys are great, but if your backend logic is lazy, you're just building a faster door with a broken lock.

It's all about the verification layer. If you aren't strict, hackers will find the gaps in your api.

  • Strict Origin Checks: Always verify the origin and rpId on the server. If a request comes from a domain you don't recognize, kill it immediately.
  • Challenge Management: Use high-entropy, single-use challenges. If you let a challenge live too long or reuse it, you're begging for a replay attack.
  • Attestation logic: In high-security sectors like healthcare or finance, check the attestation statement. It proves the key actually came from a trusted hardware module, not some software emulator.

Crucial Note: The code below is just a basic logic check. In a real app, you must perform cryptographic signature verification using the user's public key. Doing this manually is incredibly hard and prone to errors, so you should use a proven library like @simplewebauthn/server to handle the heavy lifting.

// Simplified server-side logic (NOT COMPLETE)
const verifyRegistration = (response, expectedChallenge) => {
  const { clientDataJSON } = response;
  const parsedData = JSON.parse(atob(clientDataJSON));

  // check if the challenge matches what we sent
  if (parsedData.challenge !== expectedChallenge) {
    throw new Error("Challenge mismatch. potential replay!");
  }

  // verify the origin matches our production domain
  if (parsedData.origin !== "https://myapp.com") {
    throw new Error("Invalid origin detected");
  }
  
  // WARNING: You still need to verify the cryptographic signature here!
  // Use a library like @simplewebauthn/server for this part.
  
  return true;
};

Building this right means monitoring for weird patterns, like one account suddenly adding five different passkeys in a minute. That's usually a red flag in retail or banking apps.

Final thoughts on the future of auth

So, is passwordless actually worth the headache? Honestly, yeah. Even with the weird bugs we talked about earlier, it’s still way better than watching your users reuse "Password123" everywhere.

  • Risk profile: Passkeys kill 99% of bulk phishing, which is the main way b2b apps get wrecked.
  • Better UX: No more "forgot password" tickets clogging up support.
  • ai readiness: As ai makes deepfake phishing easier, fido2 is your only real defense.

A 2024 report by Verizon found that stolen credentials still drive most breaches, making passkeys a no-brainer for security leads.

It’s not perfect, but it’s the best we got. Stay paranoid.

*** This is a Security Bloggers Network syndicated blog from MojoAuth - Advanced Authentication &amp; Identity Solutions authored by MojoAuth - Advanced Authentication & Identity Solutions. Read the original post at: https://mojoauth.com/blog/can-passkeys-be-exploited-for-account-access


文章来源: https://securityboulevard.com/2026/01/can-passkeys-be-exploited-for-account-access/
如有侵权请联系:admin#unsafe.sh