Passkeys & FIDO2 Architecture: WebAuthn Protocol Flow, Attestation & Phishing-Resistant Authentication

1. The Failure of Legacy Authentication Mechanisms

For decades, enterprise access control has depended on shared knowledge secrets—passwords. Despite complex password rotation policies, password reuse and credential stuffing attacks remain the leading root cause of enterprise breaches. Traditional multi-factor authentication (MFA)—including SMS OTPs, email verification codes, and push-based mobile notifications—is fundamentally vulnerable to SIM swapping, MFA fatigue attacks, and Adversary-in-the-Middle (AitM) phishing reverse proxies (such as Evilginx3 and Modlishka).

The FIDO2 standard—governed jointly by the FIDO Alliance and the World Wide Web Consortium (W3C)—replaces shared secrets with asymmetric public-key cryptography, delivering provably phishing-resistant authentication.

2. The FIDO2 Ecosystem: WebAuthn & CTAP2

The FIDO2 architecture connects three primary entities via two distinct protocols:

+-----------------------+              WebAuthn               +-----------------------+
|  User Browser / Host  |  |  Relying Party (RP)   |
|   (Client Platform)   |             (JavaScript)            |  (Web Server/Backend) |
+-----------------------+                                     +-----------------------+
           ||
           || CTAP2 (Client-to-Authenticator Protocol)
           || (USB, NFC, BLE)
           vv
+-----------------------+
| FIDO2 Authenticator   |
| (YubiKey / Enclave)   |
+-----------------------+

1. Web Authentication API (WebAuthn / W3C): The standardized JavaScript API embedded natively in all modern web browsers. It provides methods (navigator.credentials.create() and navigator.credentials.get()) for web applications (Relying Parties) to request cryptographic credentials.
2. Client to Authenticator Protocol (CTAP2 / FIDO Alliance): The hardware communication protocol that allows the operating system or browser to communicate with external authenticators (e.g. YubiKey via USB/NFC) or internal hardware security enclaves (Apple Secure Enclave, Windows Hello TPM, Android StrongBox).

3. WebAuthn Cryptographic Protocol Flows

A. Registration Ceremony (Public-Key Credential Creation)

1. Challenge Issuance: The Relying Party (RP) web server generates a cryptographically random 32-byte binary challenge, associates it with the user session, and sends it to the browser along with the RP ID (e.g. hackershreyansh.blog).
2. Hardware Key Generation: The browser passes the challenge and RP ID to the authenticator via CTAP2. The authenticator prompts for user presence (biometric fingerprint or PIN) and generates a unique, non-exportable asymmetric key pair (typically ECDSA P-256 or Ed25519) strictly scoped to the RP ID.
3. Attestation Statement Creation: The authenticator creates an authenticatorData structure containing the public key, credential ID, and flags. It digitally signs a hash of the client data (including the challenge) and returns the public key and attestation statement to the RP.
4. Verification & Storage: The RP verifies the digital signature against the challenge, confirms the origin matches the expected domain, and stores the public key and credential ID in the database. The private key never leaves the authenticator’s secure hardware.

B. Authentication Ceremony (Assertion Verification)

When the user logs in, the RP issues a fresh challenge. The browser requests an assertion: the authenticator verifies user presence, retrieves the private key matching the credential ID, signs the challenge concatenated with authenticatorData, and returns the signature. The server verifies the signature using the stored public key.

+-------------------------------------------------------------+
|        Why WebAuthn is Completely Immune to Phishing        |
+-------------------------------------------------------------+
  Attacker Phishing Domain: https://evil-login.com
  Legitimate Relying Party:  https://hackershreyansh.blog
                                │
  Victim enters passkey prompt on evil-login.com:
  1. Browser extracts URL origin: "https://evil-login.com"
  2. Browser computes SHA-256 hash of origin and passes to Authenticator
  3. Authenticator inspects stored credentials:
     -> Scoped to "hackershreyansh.blog"
     -> NO MATCH FOUND for "evil-login.com"!
  4. Operation REJECTED by hardware.
  ===> Zero credentials, tokens, or hashes are ever transmitted!

4. Synced Passkeys vs. Device-Bound Credentials

Modern passkey deployments are divided into two architectures:

• Synced Passkeys (Multi-Device Credentials): Cryptographically synced across an ecosystem via end-to-end encrypted keychains (Apple iCloud Keychain, Google Password Manager, 1Password). Designed for consumer usability—if a user loses their iPhone, the passkey is restored on their new device via cloud recovery.
• Device-Bound Passkeys (Hardware Security Keys): Cryptographically locked to physical hardware (e.g. YubiKey 5 Series). The private key cannot be exported or synchronized under any circumstances. Required for high-security enterprise environments, defense contractors, and zero-trust administrative workstations.

5. Hands-on WebAuthn Assertion Verification in Python

The following Python module demonstrates server-side validation of a WebAuthn authentication assertion using standard cryptographic libraries.

# WebAuthn Server-side Assertion Verifier
import hashlib
import json
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric.utils import decode_dss_signature

class WebAuthnVerifier:
    def verify_assertion(self, public_key_pem: bytes, client_data_json: bytes, auth_data: bytes, signature_der: bytes, expected_challenge: str, expected_origin: str) -> bool:
        # 1. Parse and Validate Client Data JSON
        client_data = json.loads(client_data_json.decode("utf-8"))
        
        if client_data.get("type") != "webauthn.get":
            print("[-] Invalid operation type.")
            return False
            
        if client_data.get("challenge") != expected_challenge:
            print("[-] Challenge mismatch.")
            return False
            
        if client_data.get("origin") != expected_origin:
            print(f"[-] Origin mismatch: expected {expected_origin}, got {client_data.get('origin')}")
            return False

        # 2. Construct Verification Payload: authData || SHA256(clientDataJSON)
        client_data_hash = hashlib.sha256(client_data_json).digest()
        signed_data = auth_data + client_data_hash

        # 3. Verify Cryptographic ECDSA Signature
        from cryptography.hazmat.primitives.serialization import load_pem_public_key
        public_key = load_pem_public_key(public_key_pem)

        try:
            public_key.verify(
                signature_der,
                signed_data,
                ec.ECDSA(hashes.SHA256())
            )
            print("[+] Cryptographic signature verified successfully!")
            return True
        except Exception as e:
            print(f"[-] Signature verification failed: {e}")
            return False

if __name__ == "__main__":
    print("[*] WebAuthn cryptographic engine initialized.")

6. Enterprise Passkey Migration Roadmap

• Mandate Passkey-Only Logins for Admin Roles: Decommission SMS, email OTP, and push notifications for administrative accounts in Okta, Azure AD (Entra ID), or PingFederate.
• Configure Enterprise Attestation: In high-compliance environments, configure Relying Parties to require direct attestation during registration. Verify that the authenticator’s AAGUID matches authorized corporate YubiKeys.
• Implement User-Presence and User-Verification Enforcements: Configure WebAuthn options with userVerification: "required" to mandate biometric touch or PIN input, preventing unattended workstation hijacking.

Threat Hunting & Strategic Attribution Playbook

Converting forensic findings into actionable threat intelligence requires rigorous adherence to intelligence analysis standards:

1. Diamond Model Activity Threading: Correlate the observed adversary capability (malware, exploits) and infrastructure (C2 domains, IP blocks, JARM hashes) against known threat actor profiles in MITRE ATT&CK. Establish analytical confidence using the Admiralty Code.
2. Passive DNS & Infrastructure Pivoting: Query historical passive DNS (pDNS) repositories to map the attacker’s broader hosting topology. Identify SSL/TLS certificate reuse, common WHOIS registrant attributes, and co-located command servers.
3. Defensive Engineering via MITRE D3FEND: Map identified adversary TTPs to corresponding D3FEND defensive countermeasures. Deploy canary credentials, harden process execution policies, and implement network micro-segmentation to permanently deny the threat actor operational access.
4. Automated STIX/TAXII Threat Sharing: Package validated threat intelligence into standardized STIX 2.1 JSON bundles. Automate TAXII feed publication to SIEM, SOAR, and perimeter firewall blocklists for automated threat neutralization.