implementing-hardware-security-key-authentication

What this skill does

# Implementing Hardware Security Key Authentication

## When to Use

- Deploying phishing-resistant multi-factor authentication (MFA) using FIDO2 hardware security keys for high-value accounts (administrators, developers, privileged users)
- Building a WebAuthn relying party server that supports both roaming authenticators (USB/NFC security keys) and platform authenticators (Windows Hello, Touch ID, Android biometrics)
- Migrating an existing password-based authentication system to support passkeys (discoverable credentials) as a primary or secondary authentication factor
- Enrolling YubiKey devices for an organization's workforce, including PIN setup, credential registration, and backup key provisioning
- Implementing passwordless authentication flows that comply with NIST SP 800-63B AAL3 (authenticator assurance level 3) requirements

**Do not use** without HTTPS in production (WebAuthn requires a secure origin), for systems where users cannot physically access a USB/NFC port, or as the sole authentication factor without a recovery mechanism for lost keys.

## Prerequisites

- Python 3.10+ with `fido2` (python-fido2 >= 2.0.0), `flask`, and `cryptography` libraries installed
- HTTPS-enabled web server (WebAuthn API requires secure context; localhost is exempt for development)
- FIDO2-compatible hardware security key (YubiKey 5 Series, SoloKeys, Titan Security Key) or platform authenticator
- Modern web browser supporting the WebAuthn API (Chrome 67+, Firefox 60+, Safari 14+, Edge 79+)
- Understanding of public key cryptography, challenge-response protocols, and HTTP session management

## Workflow

### Step 1: Relying Party Server Configuration

Configure the WebAuthn relying party (RP) identity and server:

- **Define RP identity**: Create a `PublicKeyCredentialRpEntity` with the relying party name (display name shown to users) and RP ID (the effective domain of the application). The RP ID must be a registrable domain suffix of the origin -- for example, `example.com` is valid for `https://auth.example.com` but `other.com` is not.
- **Initialize Fido2Server**: Instantiate the `Fido2Server` class from the python-fido2 library with the RP entity. The server handles challenge generation, attestation verification, and assertion validation.
- **Configure attestation preference**: Set the attestation conveyance preference to control whether the server requests proof of the authenticator's identity:
  - `none`: No attestation requested (simplest, recommended for most deployments)
  - `indirect`: Attestation may be provided but CA may anonymize it
  - `direct`: Full attestation chain from the authenticator's manufacturer
  - `enterprise`: Device-identifying attestation for managed environments
- **Session management**: Configure server-side sessions to store WebAuthn state between the begin and complete phases of registration/authentication ceremonies. Use secure, httponly cookies with SameSite=Strict.
- **Credential storage**: Design the database schema to store credential records: `credential_id` (binary), `public_key` (COSE key), `sign_count` (uint32 for clone detection), `user_id`, `created_at`, `last_used`, `display_name`, and `transports` (USB, NFC, BLE, internal).

### Step 2: Registration Ceremony (Credential Creation)

Implement the WebAuthn registration flow to create new credentials:

- **Begin registration**: Call `server.register_begin()` with the user entity (`PublicKeyCredentialUserEntity` containing user ID, username, and display name), the list of existing credentials for the user (to prevent duplicate registration), and options for `user_verification` and `authenticator_attachment`.
- **Authenticator selection criteria**:
  - `authenticator_attachment: cross-platform` restricts to roaming authenticators (USB/NFC keys)
  - `authenticator_attachment: platform` restricts to built-in authenticators (Touch ID, Windows Hello)
  - Omitting this field allows both types
  - `resident_key: required` forces creation of a discoverable credential (passkey) stored on the authenticator
  - `user_verification: required` enforces PIN or biometric verification on the authenticator
- **Client-side ceremony**: The browser calls `navigator.credentials.create()` with the options from the server. The authenticator generates a new key pair, stores the private key in its secure element, and returns the public key, credential ID, attestation object, and client data JSON.
- **Complete registration**: Call `server.register_complete()` with the saved state and the client response. The server verifies the attestation signature, extracts the credential public key and ID, and returns `AuthenticatorData` containing the credential data to store.
- **Store credential**: Persist the `credential_data` (contains `credential_id`, `public_key` as COSE key, and `sign_count`) to the database associated with the user account.

### Step 3: Authentication Ceremony (Assertion)

Implement the WebAuthn authentication flow to verify credentials:

- **Begin authentication**: Call `server.authenticate_begin()` with the list of registered credentials for the user (or omit for discoverable credential flows where the authenticator identifies the user). Set `user_verification` based on the assurance level required.
- **Client-side assertion**: The browser calls `navigator.credentials.get()` with the server options. The authenticator locates the matching credential, performs user verification if required, increments the signature counter, and signs the challenge with the private key.
- **Complete authentication**: Call `server.authenticate_complete()` with the saved state, registered credentials, and the client response. The server verifies the assertion signature against the stored public key and validates the signature counter has incremented (clone detection).
- **Update sign count**: After successful authentication, update the stored `sign_count` for the credential. If the new sign count is not greater than the stored value, the key may have been cloned -- flag this as a security event.
- **Discoverable credential flow**: For passwordless authentication, the user does not need to enter a username first. The authenticator presents all discoverable credentials for the RP ID, and the selected credential's `userHandle` identifies the user.

### Step 4: YubiKey Enrollment and Management

Implement organizational YubiKey provisioning workflows:

- **PIN initialization**: Before first use, a YubiKey requires a FIDO2 PIN (minimum 4 characters, 8 retries before lockout). Guide users through PIN setup using the Yubico Authenticator application or programmatically via the CTAP2 `clientPin` command.
- **Primary key enrollment**: Register the user's primary YubiKey with their account. Store the credential with a user-friendly label (e.g., "USB-A YubiKey - Office") and the authenticator's AAGUID for device identification.
- **Backup key enrollment**: Require users to register at least two security keys. The backup key should be stored separately (home, safety deposit box). Both keys must be registered to the same account so either can authenticate.
- **Key attestation verification**: For enterprise deployments, verify the attestation certificate chain to confirm the key is a genuine YubiKey from Yubico. Compare the AAGUID against Yubico's published values to identify the exact model.
- **Key lifecycle management**: Implement administrative functions to list a user's registered keys, revoke compromised keys, force re-enrollment, and audit key usage patterns (last authentication time, total authentications).

### Step 5: Passkey Migration Strategy

Plan and execute migration from passwords to passkeys:

- **Phased rollout**: Begin with voluntary passkey enrollment alongside existing password authentication. Track adoption metrics (percentage of users with passkeys, percentage of logins using passkeys vs. passwords).
- **Credential upgrade flow**: When a user authenticates with a password, prompt them to