creator/Anthropic-Cybersecurity-Skills
1
0
Fork 0
mirror of https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git synced 2026-06-14 15:04:56 +03:00
Code Issues Packages Projects Releases Wiki Activity

Add 30 new production-grade cybersecurity skills: AI security, supply chain, firmware, cloud-native, compliance, deception, crypto, threat hunting, purple team, OT, privacy

Browse Source
This commit is contained in:
mukul975
2026-03-19 19:14:23 +01:00
parent d43cc7a766
commit d833f0eab9
125 changed files with 47874 additions and 334 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/implementing-hardware-security-key-authentication/LICENSE
+201
View File
@@ -0,0 +1,201 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to the Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by the Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding any notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. Please do not remove or change
the license header comment from a contributed file except when
necessary.
Copyright 2026 mukul975
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
skills/implementing-hardware-security-key-authentication/SKILL.md
+203
View File
@@ -0,0 +1,203 @@
---
name: implementing-hardware-security-key-authentication
description: >
Implements FIDO2/WebAuthn hardware security key authentication including registration ceremonies,
authentication flows, YubiKey enrollment, and passkey migration strategies. Builds a complete
relying party server using the python-fido2 library that supports cross-platform authenticators,
resident key (discoverable credential) workflows, and user verification policies. Activates for
requests involving FIDO2 implementation, WebAuthn registration, hardware security key enrollment,
YubiKey integration, or passkey migration from password-based authentication.
domain: cybersecurity
subdomain: identity-and-access-management
tags: [FIDO2, WebAuthn, hardware-security-key, YubiKey, passkeys, passwordless-authentication, CTAP2]
version: 1.0.0
author: mukul975
license: Apache-2.0
---
# 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 register a passkey. Present the WebAuthn registration dialog immediately after successful password login to minimize friction.
- **Cross-device passkeys**: Support synced passkeys (passkeys stored in platform credential managers like iCloud Keychain, Google Password Manager, or 1Password) for users who do not have hardware security keys. These provide phishing resistance without requiring dedicated hardware.
- **Account recovery**: Design recovery flows for users who lose all their security keys:
- Recovery codes generated at enrollment time (printed, stored in password manager)
- Supervised re-enrollment by an administrator after identity verification
- Temporary time-limited password login with mandatory key re-enrollment
- Never allow recovery via email or SMS alone, as these defeat the phishing resistance
- **Password deprecation timeline**: After passkey adoption exceeds the target threshold, enforce passkey-only authentication for high-privilege accounts first, then expand to all accounts. Maintain password as a fallback during the transition window.
- **Monitoring and metrics**: Track registration success rates, authentication failure rates (wrong key, timeout, cancelled), mean time to authenticate, and the ratio of passkey to password logins.
## Key Concepts
| Term | Definition |
|------|------------|
| **FIDO2** | An umbrella term for the combination of the W3C WebAuthn API and the FIDO Alliance CTAP2 protocol, enabling passwordless and phishing-resistant authentication using public key cryptography |
| **WebAuthn** | The W3C Web Authentication API that allows web applications to create and use public key credentials via `navigator.credentials.create()` (registration) and `navigator.credentials.get()` (authentication) |
| **CTAP2** | Client to Authenticator Protocol version 2; the protocol used by the browser (client) to communicate with external authenticators over USB, NFC, or BLE |
| **Relying Party (RP)** | The web application or service that requests authentication; identified by its RP ID (a domain) and RP name (display string) |
| **Discoverable Credential (Passkey)** | A credential stored on the authenticator that can be enumerated without the RP providing a credential ID, enabling username-less authentication flows |
| **Attestation** | Cryptographic proof from the authenticator about its identity and properties; used by the RP to verify the authenticator model and manufacturer |
| **AAGUID** | Authenticator Attestation Globally Unique Identifier; a 128-bit value identifying the authenticator model (e.g., all YubiKey 5 NFC devices share the same AAGUID) |
| **Sign Count** | A monotonically increasing counter maintained by the authenticator and included in each assertion; used by the RP to detect cloned authenticators |
| **User Verification (UV)** | Local authentication on the authenticator itself (PIN, fingerprint, face recognition) that proves the person holding the authenticator is the legitimate owner |
## Tools & Systems
- **python-fido2**: Yubico's official Python library (v2.0+) providing `Fido2Server` for relying party implementation and `CtapHidDevice`/`Fido2Client` for direct authenticator communication over USB
- **YubiKey 5 Series**: Yubico hardware security keys supporting FIDO2/CTAP2, U2F, PIV, OpenPGP, and OTP; available in USB-A, USB-C, NFC, and Nano form factors
- **py_webauthn**: Duo Labs' Python WebAuthn library providing `generate_registration_options()`, `verify_registration_response()`, `generate_authentication_options()`, and `verify_authentication_response()` functions
- **Yubico Authenticator**: Desktop and mobile application for managing YubiKey FIDO2 credentials, setting PINs, and viewing registered accounts
- **WebAuthn.io / demo.yubico.com**: Online testing tools for verifying WebAuthn registration and authentication flows against real authenticators
## Common Scenarios
### Scenario: Deploying FIDO2 MFA for a Development Team
**Context**: A software company wants to replace TOTP-based MFA with hardware security keys for its 50-person development team. Developers have root access to production infrastructure and are high-value targets for phishing attacks. The company has standardized on YubiKey 5 NFC.
**Approach**:
1. Provision YubiKey 5 NFC keys (2 per developer: primary + backup) and distribute in tamper-evident packaging with initial PIN setup instructions
2. Deploy the WebAuthn relying party server integrated with the company's SSO (OAuth 2.0 / OpenID Connect) provider, configured with `authenticator_attachment: cross-platform` and `user_verification: required`
3. Run enrollment sessions where each developer registers both keys to their account, with attestation verification confirming genuine YubiKey 5 NFC AAGUIDs
4. Configure the SSO provider to require FIDO2 as the second factor for all developer accounts, with a 30-day grace period where TOTP remains available
5. Implement a self-service portal for key management: view registered keys, register replacement keys, and report lost/stolen keys (which triggers immediate credential revocation and re-enrollment)
6. After the grace period, disable TOTP for developer accounts. Monitor authentication logs for any fallback attempts and provide 1:1 support for remaining holdouts
7. Achieve 100% FIDO2 adoption for the development team, reducing phishing risk to near-zero for production infrastructure access
**Pitfalls**:
- Not requiring backup key enrollment, leading to account lockouts when a single key is lost
- Setting `user_verification: discouraged` which allows anyone who physically possesses the key to authenticate without a PIN
- Forgetting to validate the sign counter, missing cloned key attacks
- Not supporting NFC for developers who primarily work from tablets or phones
- Allowing TOTP as a permanent fallback, which undermines the phishing resistance of the FIDO2 deployment
### Scenario: Implementing Passwordless Login for a Customer-Facing Application
**Context**: An e-commerce platform wants to offer passkey-based passwordless login to its 2 million users as an alternative to passwords, reducing account takeover from credential stuffing and phishing.
**Approach**:
1. Implement WebAuthn with `resident_key: required` to create discoverable credentials that enable username-less login
2. Support both platform authenticators (Touch ID, Windows Hello, Android biometrics) and roaming authenticators (security keys) by omitting `authenticator_attachment`
3. Add a "Sign in with a passkey" button to the login page that triggers `navigator.credentials.get()` with an empty `allowCredentials` list, prompting the authenticator to present available passkeys
4. After successful passkey creation, prompt users to create a passkey on a second device for redundancy
5. Maintain password login as a fallback during the rollout period, with a persistent prompt encouraging passkey setup after each password login
6. Track metrics: passkey registration rate (target 30% in first quarter), passkey vs. password login ratio, authentication failure rates, and account takeover incidents
7. After 6 months, offer incentives (extended session duration, reduced CAPTCHA) for users who switch to passkey-only authentication
**Pitfalls**:
- Not handling the case where a user's platform authenticator (e.g., laptop Touch ID) is unavailable and they need cross-device authentication via QR code
- Assuming all users have biometric-capable devices; some will need to fall back to PIN-based verification
- Not implementing proper account recovery for users who lose access to all registered passkeys
- Ignoring browser compatibility gaps, particularly in older Safari versions on iOS
## Output Format
```
## FIDO2 Deployment Report
**Application**: auth.example.com
**RP ID**: example.com
**Date**: 2026-03-19
### Enrollment Summary
- **Total Users**: 50
- **Users with Primary Key**: 50 (100%)
- **Users with Backup Key**: 47 (94%)
- **Authenticator Models**: YubiKey 5 NFC (48), YubiKey 5C NFC (2)
### Authentication Metrics (Last 30 Days)
- **Total Authentications**: 12,847
- **FIDO2 Authentications**: 12,203 (95.0%)
- **TOTP Fallback**: 644 (5.0%) -- grace period active
- **Mean Authentication Time**: 2.3 seconds
- **Authentication Failures**: 127 (0.99%)
- User cancelled: 89
- Timeout: 23
- Invalid signature: 12
- Sign count regression (possible clone): 3
### Security Events
- **Lost Key Reports**: 2
- User A: primary key lost 2026-03-12, revoked, backup promoted, new backup enrolled
- User B: backup key damaged 2026-03-15, revoked, replacement enrolled
### Credential Details
| User | Key Label | AAGUID | Registered | Last Used | Sign Count |
|------|-----------|--------|------------|-----------|------------|
| alice | YubiKey Primary | 2fc0579f... | 2026-02-15 | 2026-03-19 | 847 |
| alice | YubiKey Backup | 2fc0579f... | 2026-02-15 | 2026-03-01 | 12 |
| bob | YubiKey Primary | 2fc0579f... | 2026-02-16 | 2026-03-19 | 631 |
```
skills/implementing-hardware-security-key-authentication/references/api-reference.md
+195
View File
@@ -0,0 +1,195 @@
# API Reference: FIDO2/WebAuthn Hardware Security Key Authentication Server
## Overview
Implements a complete WebAuthn relying party server with registration/authentication ceremonies, YubiKey enrollment, credential management, recovery codes, and audit logging. Built on python-fido2 and Flask, supporting both roaming authenticators (USB/NFC security keys) and platform authenticators (Windows Hello, Touch ID).
## Dependencies
| Package | Version | Purpose |
|---------|---------|---------|
| fido2 | >=2.0.0 | Yubico's python-fido2 library for WebAuthn relying party operations |
| flask | >=2.3 | HTTP server framework for API endpoints and session management |
| cryptography | >=41.0 | Cryptographic primitives used by python-fido2 |
Install with: `pip install fido2 flask cryptography`
## CLI Usage
```bash
# Development server on localhost (no TLS needed)
python agent.py --rp-id localhost --rp-name "My App" --port 5000
# Production with strict security settings
python agent.py --rp-id auth.example.com --rp-name "Example Corp" \
--user-verification required --attestation direct --db prod_keys.db
# Verbose logging for debugging
python agent.py --rp-id localhost --rp-name "Test" -v
```
## Arguments
| Argument | Required | Description |
|----------|----------|-------------|
| `--rp-id` | No | Relying Party ID -- must match the application domain (default: localhost) |
| `--rp-name` | No | Relying Party display name shown in authenticator prompts (default: FIDO2 Demo) |
| `--host` | No | Server bind address (default: localhost) |
| `--port` | No | Server port (default: 5000) |
| `--db` | No | SQLite database path for credentials and users (default: webauthn.db) |
| `--attestation` | No | Attestation preference: none, indirect, direct, enterprise (default: none) |
| `--user-verification` | No | UV requirement: required, preferred, discouraged (default: preferred) |
| `-v, --verbose` | No | Enable debug logging |
## API Endpoints
### Registration
#### `POST /api/register/begin`
Start the WebAuthn registration ceremony.
**Request body:**
```json
{
"username": "alice",
"display_name": "Alice Smith",
"resident_key": true
}
```
**Response:** PublicKeyCredentialCreationOptions (JSON-serialized)
#### `POST /api/register/complete`
Complete registration with the authenticator's response.
**Request body:** Serialized PublicKeyCredential from `navigator.credentials.create()`
**Response:**
```json
{
"status": "OK",
"recovery_codes": ["A1B2C3D4", "E5F6G7H8", ...],
"message": "Save these recovery codes securely."
}
```
### Authentication
#### `POST /api/authenticate/begin`
Start the WebAuthn authentication ceremony.
**Request body:**
```json
{
"username": "alice"
}
```
Omit `username` for discoverable credential (passwordless) flow.
**Response:** PublicKeyCredentialRequestOptions (JSON-serialized)
#### `POST /api/authenticate/complete`
Complete authentication with the authenticator's assertion.
**Request body:** Serialized PublicKeyCredential from `navigator.credentials.get()`
**Response:**
```json
{
"status": "OK",
"username": "alice"
}
```
### Key Management
#### `GET /api/keys`
List all registered security keys for the authenticated user.
#### `POST /api/keys/<id>/revoke`
Revoke a security key. Requires at least one remaining active credential.
#### `PUT /api/keys/<id>/label`
Update a key's display label.
### Recovery
#### `POST /api/recover`
Authenticate using a recovery code when all keys are unavailable.
**Request body:**
```json
{
"username": "alice",
"recovery_code": "A1B2C3D4"
}
```
### Admin
#### `GET /api/admin/stats`
Deployment statistics: total users, credentials, backup key adoption, authentication metrics.
#### `GET /api/admin/audit-log?limit=100`
Authentication event audit trail with timestamps, usernames, event types, and IP addresses.
## Key Functions
### User Management
#### `create_user(conn, username, display_name)`
Creates a user with a cryptographically random 32-byte user handle.
#### `get_user_by_username(conn, username)` / `get_user_by_handle(conn, user_handle)`
User lookups by username (standard flow) or user handle (discoverable credential flow).
### Credential Management
#### `store_credential(conn, user_id, credential_id, public_key, sign_count, ...)`
Persists a WebAuthn credential with AAGUID, label, transport hints, and discoverable flag.
#### `get_user_credentials(conn, user_id)`
Retrieves all active (non-revoked) credentials for a user.
#### `revoke_credential(conn, credential_db_id, user_id)`
Soft-revokes a credential. Prevents revocation of the last remaining credential.
#### `update_sign_count(conn, credential_id, new_count)`
Updates sign count and last-used timestamp after successful authentication. Sign count regression is logged as a security event (possible cloned key).
### Recovery
#### `generate_recovery_codes(conn, user_id, count=8)`
Generates 8 one-time recovery codes (stored as SHA-256 hashes). Previous codes are invalidated.
#### `verify_recovery_code(conn, user_id, code)`
Verifies and consumes a recovery code (single-use).
### Helpers
#### `build_credential_descriptors(creds)`
Converts stored credentials to `PublicKeyCredentialDescriptor` list for WebAuthn ceremonies.
#### `reconstruct_credential_data(creds)`
Rebuilds `AttestedCredentialData` objects from database records for python-fido2 verification.
## Database Schema
| Table | Purpose |
|-------|---------|
| `users` | User accounts with random user handles, usernames, and passkey-only flag |
| `credentials` | WebAuthn credentials with public keys, sign counts, AAGUIDs, and revocation status |
| `auth_events` | Audit log of all registration, authentication, revocation, and recovery events |
| `recovery_codes` | Hashed one-time recovery codes with usage tracking |
## Security Features
| Feature | Implementation |
|---------|---------------|
| Phishing resistance | Origin binding via WebAuthn RP ID verification |
| Clone detection | Sign count validation with regression warnings |
| Recovery codes | SHA-256 hashed, single-use, auto-invalidated on regeneration |
| Session security | Secure, HttpOnly, SameSite=Strict cookies |
| Key revocation | Soft delete with minimum-one-key enforcement |
| Audit trail | All auth events logged with IP, user agent, and timestamp |
| Attestation verification | Configurable attestation preference for enterprise key verification |
skills/implementing-hardware-security-key-authentication/scripts/agent.py
+1009
View File
File diff suppressed because it is too large Load Diff