Pass the Passkey: A Novel Attack Surface in Passwordless Authentication

Aug 05, 2026 06:22 AM - 2 hours ago 3

Executive Summary

This article analyzes caller onslaught classes against passwordless authentication, focusing connected Google’s synced passkey ecosystem and the Cloud Authenticator utilized by desktop clients. The attacks show really malware connected a compromised endpoint tin misuse onboarding, betterment and instrumentality spot workflows to return complete passkey-protected accounts. We show really an attacker tin authenticate without personification interaction, bypass personification verification requirements and extract each synced passkey backstage keys.

After decades of breaches and billions successful losses, the onslaught vectors that defined the era of passwords and shared secrets are yet starting to fade. Passkeys switch passwords and accepted multi-factor authentication (MFA) pinch public-key cryptography, decreasing full classes of attacks that person dominated the threat scenery for years.

With nary shared concealed to steal, reuse aliases phish, galore of an attacker’s astir reliable devices are becoming obsolete. This represents a important disruption for the credential theft market.

Attackers, however, persist. They evolve, and defenders must hole for a caller procreation of attacks. As passkeys go wide adopted and standard to billions of accounts, defenders must hole for caller onslaught surfaces, immoderate of which we disclose successful our research.

This article is portion 3 successful our bid examining passkey take from a information perspective. If you haven’t publication the erstwhile parts, we urge starting here:

Part 1: The Art of the Invisible Key – Passkey Global Breakthrough

Part 2: Google Authenticator: The Hidden Mechanisms of Passwordless Authentication

Palo Alto Networks customers are amended protected from this caller onslaught vector done the pursuing products and services:

  • Cortex Cloud Identity Security
  • Idira Threat Detection and Response
  • Idira Endpoint Privilege Manager
  • Idira Privilege Access Management 

If you deliberation you mightiness person been compromised aliases person an urgent matter, interaction the Unit 42 Incident Response team.

Setting the Stage

Google’s synced passkey implementation is peculiarly instructive owed to its standard and really it creates a higher modular for backstage cardinal protection successful 2 captious ways:

  • Private keys are generated and utilized wrong a cloud-enclave isolation environment
  • Hardware-backed, client-device-bound keys power entree to cloud-based cryptographic operations, attesting to the user’s beingness connected a trusted device

This article builds connected the architectural study from Part 1 and Part 2 of our erstwhile articles successful this series. We now displacement from really passkeys are built and deployed to really attackers tin misuse them.

We coming 3 caller attacks that alteration relationship takeover of passkey-protected accounts. Each onslaught challenges a different halfway presumption of passkey authentication security. When a customer authenticates pinch a passkey, the pursuing is expected:

  • Users supply explicit consent connected the instrumentality to verify user presence
  • For MFA, users must besides unlock the instrumentality to verify biometric (i.e., thing you are) aliases knowledge-based (i.e., thing you know) authentication factors
  • Passkey backstage keys cannot beryllium shared aliases copied

The Google documentation reflects these halfway assumptions, describing the passkey login process arsenic a unafraid replacement to passwords (as shown successful Figure 1).

A screenshot of Google Account Help page explaining passkeys. It highlights that passkeys are much unafraid than passwords arsenic they cannot beryllium shared, copied, aliases accidentally fixed away. Using a passkey to motion successful ensures entree to your instrumentality and its unlocking.Figure 1. Google documentation describes passkeys arsenic requiring instrumentality access, instrumentality unlock, and non-shareable credentials.

Challenging these expectations is simply a class of attacks we've nicknamed Pass-ta-key. This playful, layered sanction blends the connection passkey and the building “pass the key,” pinch a ray motion to the conception of sheet of pasta, illustrating really tangled this cardinal implementation tin get.

These attacks each expose a different weakness successful practice:

  • Pass-ta-key attack: An attacker takes complete an relationship protected by a Google-synced passkey utilizing malware moving connected the victim’s device, without requiring privilege escalation, instrumentality unlock aliases personification interaction
  • Silver Pass-ta-key attack: An attacker deceives the Google Cloud Authenticator into believing the unfortunate has unlocked the instrumentality pinch biometrics, starring to afloat relationship takeover without utilizing the victim’s instrumentality during authentication
  • Golden Pass-ta-key attack: An attacker tin extract each synced passkeys successful a shape that allows them to beryllium shared aliases sold connected the credential achromatic market

These attacks show really malware tin utilization synced passkeys, moreover erstwhile providers adhd hardware-backed protections to unafraid credentials wrong the unreality authenticator.

Disclaimer: This investigation progressive responsible and ethical information analysis. We responsibly disclosed each presented exploits. The unreality authenticator exemplary is utilized by various passkey providers crossed aggregate browsers and platforms. This work, however, focuses connected Google Password Manager successful Chrome connected Windows, specifically connected devices equipped pinch a Trusted Platform Module (TPM). All presented attacks trust connected malware already existing connected the victim’s instrumentality during the first stage.

Stage Zero Reconnaissance

Before attempting immoderate of the attacks, the attacker needs visibility into really passkeys are utilized wrong the victim’s account. On a compromised endpoint, this visibility is readily available.

Chrome locally stores synced passkey information arsenic portion of its synchronization process. On Windows, Chrome persists this information arsenic proto-encoded WebauthnCredentialSpecifics records, which correspond synced WebAuthn credentials, wrong its sync database:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Accessing these records does not require elevated privileges. The records let an attacker to enumerate wherever the unfortunate uses passkeys, on pinch associated usernames, credential identifiers and the encrypted backstage key.

After identifying a work wherever the unfortunate uses passkeys, an attacker tin effort to authenticate arsenic the victim.

The superior situation for attackers is bypassing the protection of the backstage key, which is utilized to motion authentication challenges. This backstage cardinal is secured by a maestro key. While an encrypted type of this maestro cardinal is stored connected each customer device, only the unreality authenticator tin decrypt it.

Despite this security, the architecture remains susceptible to exploitation. The pursuing sections item methods attackers could usage to utilization strategy mechanisms, authenticate arsenic the victim, and discuss passkey-secured accounts.

Device Identity Impersonation: The Pass-Ta-Key Attack

Our first onslaught is the astir straightforward approach, which involves taking complete a passkey-protected relationship by mimicking the behaviour of Google Password Manager and Chrome during morganatic authentication. In a normal flow, Chrome sends a petition to the unreality authenticator, signed utilizing the device’s hardware-backed keys.

Unlike a morganatic personification travel that requires personification relationship and instrumentality unlock, this onslaught shows really malware tin get the required signature silently, without personification consent, biometrics, instrumentality unlock aliases elevated privileges.

To understand this, we attraction connected Chrome’s instrumentality personality key, which represents customer instrumentality possession to the unreality authenticator. As antecedently explained (part 2: Login pinch Synced Passkey and Device Key Signature), generating the required assertion involves signing information sent to the unreality authenticator utilizing 1 of the device’s hardware-backed keys. This is the personality cardinal aliases the personification verification cardinal (UV key).

Although some keys are hardware-bound, they are not accessed successful the aforesaid way. For the personality key, Chrome creates the conditions that let it to petition a signature while moving arsenic a personification without elevated privileges and without triggering instrumentality unlock protections.

On Windows, Chrome calls the NcryptCreatePersistedKey usability without assigning a cardinal name, making the TPM-backed cardinal ephemeral and preventing it from being persisted to disk. Instead of storing the backstage cardinal wrong the TPM, Chrome calls NcryptExportKey to export the cardinal arsenic an NCRYPT_OPAQUE_KEY_BLOB, which instructs the TPM to encrypt the backstage cardinal utilizing a TPM-resident key. The resulting blob is stored arsenic wrapped_identity_private_key successful the passkey_enclave_state file, making it disposable for early usage connected the aforesaid beingness TPM.

Malware tin extract this wrapped_identity_private_key from disk aliases Chrome’s memory. It tin past invoke cryptographic operations utilizing modular Windows Cryptography API: Next Generation (CNG) APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash), without elevated privileges, mimicking Chrome’s ain actions.

Having established that malware tin make the required signature, we now item the afloat Pass-ta-key onslaught travel (as shown successful Figure 2). This travel allows a distant attacker pinch unprivileged malware connected the victim’s instrumentality to authenticate arsenic the victim.

 Relying Party, Attacker, Infected Victim, and Cloud Authenticator. The floor plan shows interactions for illustration "Log successful pinch passkey," "Noise NX handshake," and "Identity Key Signature". The process moves horizontally pinch lines and arrows indicating the travel of steps.Figure 2. Pass-ta-key onslaught flow.

The onslaught travel consists of the pursuing phases:

  1. After collecting the victim’s synced passkey records (Stage Zero: Reconnaissance), the attacker selects a targeted relationship and initiates a passkey login
  2. The relying statement responds pinch a caller authentication challenge
  3. The attacker initiates a WebSocket handshake pinch the Google Cloud Authenticator
  4. Using the hash of that handshake, the attacker interacts pinch the victim’s TPM and uses the extracted personality cardinal to motion the handshake hash together pinch the assertion request
  5. The attacker sends an assertion petition to the unreality authenticator, including the personality cardinal signature
  6. From the unreality authenticator’s perspective, the petition appears to beryllium a trusted instrumentality making a valid request, truthful it produces a valid assertion response
  7. This assertion is past forwarded to the relying party, completing authentication and giving the attacker afloat power of the victim’s account

Video 1 demonstrates the onslaught arsenic it would unfold successful practice. (We person blurred the names of the relying parties to debar naming.)

Video 1. Example of a successful Pass-ta-key attack.

As the video begins, the surface splits betwixt the attacker's terminal and the victim's desktop. The video first shows the attacker establishing a command-and-control (C2) listener, passively waiting for victims to connect.

On the victim’s machine, the Trojan executes arsenic a modular user, without elevated privileges. Once active, it collects the victim’s encrypted, synced passkeys and sends them backmost to the attacker’s C2 server. This provides visibility into the victim’s disposable passkeys.

The attacker selects a target, specified arsenic a messaging exertion relationship protected by a passkey, navigates to the exertion and chooses Login pinch passkey. The relying statement past responds pinch a caller authentication challenge.

Next, the attacker initiates connection pinch the Google Cloud Authenticator. After completing the handshake, the attacker triggers the Trojan to usage the device’s personality cardinal to motion the required data. Specifically, it uses the hash of the handshake mixed pinch the hash of the serialized assertion request.

The attacker past attaches this signature to the petition sent to the unreality authenticator. The unreality authenticator returns the requested assertion. The attacker forwards this valid assertion to the relying statement and successfully logs successful arsenic the victim.

UV Flag: When MFA Depends connected a Single Bit

The Pass-ta-key onslaught is effective erstwhile the relying statement does not strictly require personification verification. Many relying parties configure WebAuthn’s userVerification parameter arsenic preferred alternatively than required to support divers devices and personification experiences, making them susceptible to this attack.

When a relying statement explicitly requires personification verification, 1 would expect the unreality authenticator to cull requests that are not signed utilizing a cardinal gated by PIN aliases biometric verification. Surprisingly, this is not the case.

The unreality authenticator returns a valid assertion sloppy of whether the petition was signed utilizing the personality cardinal aliases the UV key. The quality comes down to a azygous spot successful the authenticator data, the User Verified (UV) flag.

When the assertion is signed utilizing the UV key, this emblem is group to 1. When it is signed utilizing the personality key, the emblem remains 0.

While the Pass-ta-key onslaught produces cryptographically valid assertions matching the relying party’s nationalist key, our testing shows attacks typically neglect erstwhile personification verification is required because the UV emblem remains unset. For example, erstwhile attempting the onslaught against a passkey-protected GitHub account, the attacker receives an correction message, arsenic shown successful Figure 3.

A screenshot of a GitHub login surface pinch a information logo supra the matter "Sign successful to GitHub." A reddish correction connection states, "Unable to motion successful pinch your passkey. Please motion successful pinch your password."Figure 3. Message from GitHub passkey login failure.

Although authentication is typically rejected erstwhile personification verification is required, this behaviour is not ever consistently enforced crossed relying parties. In our testing, we identified relying parties that accepted authentication because they did not decently validate the UV flag. This allowed the onslaught to win contempt the absence of personification verification.

The deficiency of validation efficaciously reduces the authentication process to a azygous factor. By compromising only the instrumentality personality key, the attacker is capable to authenticate successfully and return complete the account, moreover though MFA is required.

We reported this rumor to the affected relying parties.

Video 2 demonstrates this behaviour successful believe connected eBay. Although eBay sets the userVerification parameter to required, the demo signaling shows a successful passkey login utilizing the described technique, without immoderate personification relationship aliases further authentication factors.

We captured this signaling earlier eBay fixed the issue. Following our report, eBay addressed this verification spread and now decently validates the UV flag.

Video 2. Pass-ta-key onslaught succeeds contempt the absence of personification verification, moreover erstwhile the UV is required.

Pending Attacker: The Silver Pass-Ta-Key Attack

When an relationship is protected by stronger authentication requirements, specified arsenic for financial aliases national personality systems, the attacker must besides bypass personification verification. This initially appears to beryllium a important challenge.

The unreality authenticator requires a connection signed pinch the UV cardinal to group the UV flag. Client relationship controls entree to this key, arsenic the OS validates the personification via the aforesaid system utilized for instrumentality unlock. Without escalating to strategy privileges aliases physical access to the unfortunate device, an attacker has nary evident way to get specified access.

Attackers tin bypass this situation done the pursuing mechanism:

  • Instead of bypassing entree to the UV key, the attacker invalidates the existing cardinal registered successful the unreality authenticator and registers a recently generated cardinal nether their control
  • Once the attacker-controlled cardinal is registered, immoderate connection signed pinch it is accepted by the unreality authenticator arsenic if the personification had successfully performed instrumentality unlock

Figure 4 demonstrates the attacker-side authentication travel successful the Silver Pass-ta-key attack, focusing connected the authentication shape aft the attacker-controlled UV cardinal is registered.

 Relying Party, Attacker, Infected Victim, and Cloud Authenticator. Each entity is successful a colored box. Arrows show the travel of communication, including a "Noise NK handshake" to the Attacker, a "Fake UV Key signature" to Google Cloud Authenticator, and an "assertion response" returning to Relying Party.Figure 4. Attacker-side authentication travel successful the Silver Pass-ta-key attack.

This attack has important implications. It allows the attacker to afloat automate authentication crossed each the victim’s accounts without quality interaction, moreover wherever personification verification is enforced. Furthermore, the attacker nary longer needs unrecorded entree to the victim’s instrumentality during authentication.

Unlike the erstwhile attack, which required progressive malware connected the victim’s instrumentality for each authentication, the Silver onslaught provides reusable access. This allows the attacker to entree the victim’s passkey-protected accounts from their ain environment, without requiring the victim’s instrumentality to beryllium online aliases active. Ultimately, this enables relationship takeover crossed each passkeys associated pinch the unfortunate without requiring elevated privileges.

Invalidating the Existing User Verification Key

To transportation retired this attack, the first nonsubjective is to invalidate the existing UV cardinal associated pinch the target device. From the erstwhile attack, we learned really an attacker tin usage unprivileged malware to motion attacker-controlled requests pinch the instrumentality personality cardinal and nonstop them to the unreality authenticator. The attacker tin leverage this capacity to rumor a device/forget bid connected behalf of the victim. A simpler action is to straight delete the victim’s passkey_enclave_state file, arsenic location are nary built-in protections that forestall its removal.

Regardless of the method, the adjacent clip the personification attempts to usage a passkey, Chrome is forced to re-onboard the device. This occurs either because Chrome nary longer has entree to the instrumentality cardinal aliases because the unreality authenticator nary longer recognizes the instrumentality arsenic registered.

Exploiting the Onboarding Flow

On Windows, instrumentality onboarding is only completed aft the 2nd usage of a passkey connected the aforesaid device. During the first use, Chrome originates onboarding pinch the unreality authenticator successful the inheritance while prompting the personification to participate the Google Password Manager (GPM) betterment PIN.

If Chrome were to create the UV cardinal astatine this point, it would besides trigger a Windows Hello prompt, requiring the personification to authenticate again utilizing biometrics aliases a PIN. Since some steps whitethorn impact a PIN, presenting them back-to-back successful the aforesaid travel tin beryllium confusing and lead to personification errors. To debar this, Chrome defers the creation of the UV key.

Instead, the instrumentality is initially registered successful a uv_key_pending state. During this first interaction, the GPM betterment PIN satisfies personification verification, and the existent UV cardinal is only created and registered during the adjacent passkey use, erstwhile the further punctual is nary longer needed.

After forcing the unfortunate into this re-registration state, the attacker tin utilization the uv_key_pending condition. In their ain environment, the attacker generates an asymmetric cardinal pair. They past nonstop a device/add_uv_key bid to the unreality authenticator, providing the attacker-controlled nationalist cardinal arsenic the UV key.

The unreality authenticator does not validate the attestation of recently registered UV keys to verify whether they originate from unafraid hardware. As a result, the attacker-controlled cardinal is stored alongside the morganatic instrumentality personality key:

devices[device_id] =

{

    hw: identity_public_key,

    uv: (Attacker-controlled) uv_public_key

}

From this constituent on, the attacker tin usage the forged UV cardinal to petition signatures for immoderate passkey associated pinch the unfortunate and get assertions pinch the UV spot set. This provides entree to high-value accounts moreover erstwhile personification verification is enforced and validated.

Stealing the Master Key: The Golden Pass-Ta-Key Attack

In this attack, the attacker efficaciously gains the unreality authenticator’s superpower, the expertise to decrypt synced passkeys. This is peculiarly impactful because it undermines the intended protection mechanism.

The passkey’s backstage cardinal is protected utilizing a symmetric maestro cardinal called the information domain concealed (SDS). This maestro cardinal is not straight accessible, it is stored connected the instrumentality arsenic an encrypted wrapped_secret. Only the unreality authenticator tin decrypt this wrapped_secret utilizing its device-specific cardinal (wrapping_key) wrong its isolated environment, arsenic noted successful Figure 5.

A sketch showing a process betwixt a customer instrumentality and a unreality authenticator. Arrows bespeak the travel from customer instrumentality to unreality authenticator.Figure 5. Synced passkey decryption wrong the unreality authenticator.

Figure 5. Synced passkey decryption wrong the unreality authenticator.

This creation intends to protect synced passkeys moreover if the customer instrumentality is compromised. As Google noted successful consequence to 1 of our vulnerability reports:

“The (cloud) enclave authenticator’s superior usability is to make it difficult to bargain passkey backstage data, which would beryllium an evident target for malware if it were locally available.”

The information of this exemplary yet hinges connected the protection of the 32-byte SDS. If an attacker is capable to get the SDS, they efficaciously summation the expertise to decrypt each synced passkeys for that account. This allows them to authenticate arsenic a afloat verified personification and return complete each work wherever the unfortunate relies connected passkeys.

Leaking the SDS

This concealed should ne'er beryllium exposed to the customer device, moreover during instrumentality nonaccomplishment aliases relationship recovery. However, we unexpectedly recovered the SDS coming successful Chrome’s logs during registration pinch the unreality authenticator, simply by opening chrome://device-log/FIDO, arsenic noted successful Figure 6.

A screenshot showing a log introduction pinch blurred delicate information. It displays a JSON formatted connection containing the bid "keys/wrap" and the intent branded arsenic "security domain secret."Figure 6. The SDS (the passkey maestro key) is exposed successful plaintext successful the instrumentality log.

In the existent Chrome implementation, each instrumentality joining aliases rejoining an account’s information domain retrieves the SDS from the betterment cardinal store, Google’s Trusted Vault service. The unreality authenticator includes a system that allows Chrome to facilitate the betterment travel wherever the cardinal cannot beryllium decrypted connected the customer device, nevertheless this system is not used. Instead, Chrome recovers the SDS successful an accessible form.

One imaginable mentation is needing to standardize the instrumentality subordinate and betterment process crossed platforms. Unlike desktop environments, Google Password Manager connected iOS and Android does not trust connected the unreality authenticator and must get the maestro cardinal to decrypt synced passkeys. As a result, Chrome appears to travel the aforesaid betterment model, moreover though the unreality authenticator could alteration a much isolated approach.

Although Google removed this concealed from Chrome’s logging output following our report, the SDS is still sent to the customer and remains accessible successful Chrome’s process memory. If the attacker forces the unfortunate to re-register pinch the unreality authenticator and knows the shape to look for, they tin extract the SDS straight from memory.

The Golden Pass-ta-key onslaught allows afloat relationship takeover done the pursuing steps:

  1. The attacker forces Chrome to trigger a caller onboarding utilizing the aforesaid mechanisms arsenic the Silver Pass-ta-key attack
  2. The attacker monitors the strategy for the recreation aliases modification of the passkey_enclave_state
  3. Once the record is recreated/modified, the attacker dumps Chrome’s process representation and extracts the SDS, which is temporarily coming successful plaintext
  4. The attacker sounds the WebauthnCredentialSpecifics records from Chrome’s sync database (Stage Zero: Reconnaissance)
  5. Using the extracted SDS, the attacker decrypts the encrypted fields successful each grounds and recovers the corresponding passkey backstage keys
  6. The attacker uses the recovered backstage keys to motion the relying party’s situation and successfully authenticates arsenic the victim

Figure 7 shows really an attacker would usage the SDS to decrypt passkeys and forge a valid authentication response.

A sketch illustrating an authentication onslaught involving entities for illustration "Relying Party," "Attacker," "Infected Victim," and "Cloud Authenticator." The travel includes encrypted passkeys and a "Fake Authenticator" pinch steps branded "challenge" and "assertion response." The attacker extracts a "Security Domain Secret."Figure 7. Flow of the Golden Pass-ta-key attack.

Video 3 shows really an attacker uses the stolen SDS to log successful to a high-value relationship (in this case, a crypto exchange).

Video 3. How an attacker uses the stolen SDS to log successful to a high-value account.

The Golden Pass-ta-key onslaught has a importantly broader impact. Beyond the reusable entree from the attacker’s environment, the SDS allows the attacker to decrypt each existing passkeys arsenic good arsenic immoderate early passkeys created for the account.

While the Silver onslaught is mitigated by unregistering aliases re-enrolling the device, the Golden onslaught provides beardown persistence. Even if a discuss is detected, remediation is limited. In Google’s existent implementation, location is nary measurement to rotate aliases revoke the SDS, meaning each existent and early synced passkeys stay protected by the aforesaid maestro key.

Mitigations

Enforce Strict User Verification (UV) Validation

Relying parties should require userVerification = required and validate the UV emblem successful each authentication responses. Failure to enforce this cheque tin trim authentication to a azygous factor. Figure 8 beneath shows the authenticator information layout.

 User Verified (UV) result" successful the Flags section, clarifying that "1 intends the personification is verified" and "0 intends the personification is not verified."Figure 8. Authenticator information layout. Source: W3C, Web Authentication.

Validate Device Key Registration and Attestation

Credential managers should verify the root and attestation of recently registered instrumentality keys, including UV and personality keys. Accepting arbitrary keys without validation allows unauthorized cardinal registration and bypass of personification verification requirements.

Harden Recovery and Device Re-Registration Flows

Credential head betterment PIN prompts are typically associated pinch onboarding aliases relationship recovery, not regular passkey authentication. Unexpected aliases repeated prompts during normal passkey usage whitethorn bespeak re-triggering of onboarding aliases recovery, perchance owed to phishing attempts aliases section manipulation of passkey state.

These flows are security-sensitive because betterment operations tin re-establish instrumentality spot and reconstruct entree to synced credentials. In the scenarios from our research, triggering betterment enabled registration of caller verification keys aliases vulnerability of cardinal worldly utilized to decrypt synced passkeys.

Monitoring agents should observe and restrict unnecessary re-triggering of onboarding and betterment flows, particularly aft deletion aliases modification of section passkey authorities files. Additional verification should beryllium required earlier re-establishing instrumentality spot aliases recovering synced credentials.

Prevent Exposure of Sensitive Key Material connected the Client

Sensitive worldly specified arsenic the maestro cardinal should not beryllium exposed to the client, including done representation aliases logs. Instead, credential managers should usage designs wherever cryptographic operations are performed connected behalf of the client, without transferring the underlying cardinal worldly to the customer environment.

Restrict Access to Local Passkey Data

Access to passkey-related storage, specified arsenic Chrome’s sync database and section authorities files (e.g., passkey_enclave_state), should beryllium constricted to the browser process and protected done level entree controls. This reduces the expertise to enumerate credentials, manipulate onboarding authorities aliases entree device-bound cardinal worldly from a compromised endpoint.

Improve Detection of Abnormal Passkey Usage

WebAuthn defines a signature antagonistic (signCount) system intended to thief relying parties observe cloned aliases unexpectedly reused credentials. In accepted authenticators, the antagonistic increases pinch each authentication cognition and tin supply a awesome of abnormal credential usage.

In synchronized passkey systems, authentication assertions commonly incorporate a changeless signCount value. As a result, relying parties and credential providers person constricted visibility into unauthorized usage of synced credentials, including scenarios wherever passkeys are extracted aliases reused from unexpected environments.

Google noted that globally accordant signature counters are difficult to instrumentality successful synchronized passkey systems that run crossed aggregate devices and platforms, peculiarly erstwhile assertions originate from independent clients.

Credential managers that centrally coordinate authentication operations should see implementing coordinated signature antagonistic mechanisms that relationship for synchronization and multi-device consistency challenges. Such mechanisms tin amended visibility and discovery of unexpected credential usage aliases passkey reuse crossed environments.

Conclusion

Passkeys correspond a meaningful measurement guardant successful authentication security. By eliminating shared secrets, they trim full classes of attacks that person historically led to wide relationship compromise. This changes the economics of credential theft and forces attackers to adopt caller techniques.

The attacks presented successful this investigation do not break the underlying cryptography. Instead, they utilization gaps betwixt creation assumptions and real-world implementations. These gaps include:

  • Trust placed successful customer devices
  • Inconsistencies successful relying statement validation
  • Weaknesses successful onboarding and betterment flows

When mixed pinch malware connected the endpoint, these gaps alteration relationship takeover scenarios that bypass the guarantees passkeys are expected to provide.

A cardinal takeaway is that endpoint discuss remains a captious portion of the threat model. When authentication decisions trust connected signals from the user’s device, an attacker pinch entree to that instrumentality tin manipulate those signals successful ways that are difficult to detect. Hardware-backed keys, unafraid enclaves and unreality isolation importantly raise the bar, but they do not afloat destruct this risk.

Passkey deployments should beryllium treated arsenic 1 furniture successful a broader information strategy. Relying parties must enforce strict validation, including due handling of the personification verification signal. Platform providers should proceed hardening onboarding and betterment flows, and organizations should put successful protections against malware and representation entree connected endpoints.

As take continues to grow, truthful will attacker liking successful this space. Understanding these emerging onslaught paths is basal to ensuring passwordless authentication delivers its intended information benefits successful real-world conditions.

Palo Alto Networks customers are amended protected from the threats discussed supra done the pursuing products:

Cortex Cloud Identity Security

Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) and Identity Threat Detection and Response (ITDR). It provides clients pinch the basal capabilities to amended their identity-related information requirements by providing visibility into identities, and their permissions, wrong unreality and instrumentality environments. This helps accurately observe misconfigurations and unwanted entree to delicate data. It besides allows real-time study surrounding usage and entree patterns.

Idira Threat Detection and Response

Idira Threat Detection and Response (TDR) enables information teams to antagonistic identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using adjacent real-time detection, powered by CORA AI, and leveraging Idira’s visibility crossed aggregate contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP tin use automated, tailored non-disruptive in-session consequence to incorporate and minimize imaginable identity-based threats.

Idira Endpoint Privilege Manager

Idira Endpoint Privilege Manager (EPM) enables enterprises to trim risk, fulfill compliance, and streamline operations. It helps instrumentality slightest privilege via policy-driven elevation and removal of opinionated admin rights, and blocks risky actions, specified arsenic execution of unvetted applications and entree to representation of different processes, while providing audit-ready grounds and unified personality governance. Automation and consolidation amended ratio and support Zero Trust strategies, strengthening information without slowing the business.

Idira Privilege Access Management

Idira Privilege Access Management unifies privileged entree crossed human, machine, and agentic identities to unafraid unreality entree crossed multi-cloud environments. Building connected proven PAM, it delivers centralized secrets guidance alongside modern controls for illustration Just-in-Time entree and Zero Standing Privileges. This enforces accordant least-privilege information crossed on-premises, cloud, and SaaS targets.

If you deliberation you whitethorn person been compromised aliases person an urgent matter, get successful touch pinch the Unit 42 Incident Response team aliases call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings pinch our chap Cyber Threat Alliance (CTA) members. CTA members usage this intelligence to quickly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn much astir the Cyber Threat Alliance.

Additional Resources

  • The Art of the Invisible Key: Passkey Global Breakthrough – CyberArk
  • Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication – Palo Alto Networks Unit 42
More