> ## Documentation Index
> Fetch the complete documentation index at: https://docs.socket.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Passkey Security: WebAuthn-Powered Wallet Authentication

> Learn how SocketFi uses WebAuthn passkeys for wallet authentication — private key protection, phishing resistance, and device-bound cryptographic signing.

Every SocketFi wallet is secured by a passkey — a cryptographic credential built on the WebAuthn standard. Passkeys replace the weak links in traditional authentication (passwords that can be stolen, seed phrases that can be lost) with device-bound asymmetric cryptography. The private key never leaves the user's hardware. Authentication never transmits a shared secret. Credentials are origin-bound, meaning they only work on the site they were registered with, providing structural resistance to phishing.

## What is WebAuthn?

WebAuthn (Web Authentication) is an open authentication standard developed by the FIDO Alliance and W3C. It's supported natively by Apple, Google, Microsoft, and all major browsers. SocketFi builds on WebAuthn because it provides cryptographic-grade authentication without any password or seed phrase that could be stolen, guessed, or lost.

WebAuthn uses **asymmetric key cryptography**: a key pair is generated on the user's device during registration. The private key stays on the device, protected by the device's secure hardware. The public key is registered with SocketFi. Future authentications work by signing a server-issued challenge with the private key — only the holder of the private key can produce a valid signature, and the private key never has to leave the device to prove this.

## Why the private key never leaving the device matters

In traditional password-based systems, authentication requires transmitting a shared secret (the password) to a server, which then verifies it. This creates multiple attack surfaces: the server can be breached, the transmission can be intercepted, and the password can be phished.

With passkeys, the private key never moves:

```text theme={null}
Traditional password flow:
User enters password  ──►  Transmitted to server  ──►  Verified
                           (can be intercepted,          (server stores
                            phished, or leaked)           a hash that can
                                                          be cracked)

Passkey flow:
Challenge issued  ──►  Device signs with private key  ──►  Signature verified
                       (private key stays in                (only the public key
                        Secure Enclave / TPM / TEE)         lives on the server)
```

A database breach at SocketFi exposes only public keys — mathematically useless to an attacker who doesn't hold the corresponding private key on the user's device.

## Device security hardware

Modern devices protect passkey private keys using dedicated secure hardware:

| Platform               | Secure Hardware                                   |
| ---------------------- | ------------------------------------------------- |
| iPhone / iPad          | Apple Secure Enclave                              |
| Mac                    | Apple Secure Enclave (T2 chip or Apple Silicon)   |
| Android                | Trusted Execution Environment (TEE) or Titan chip |
| Windows                | Trusted Platform Module (TPM)                     |
| Hardware security keys | Built-in secure element (e.g., YubiKey)           |

The operating system enforces that private key material cannot be exported from this hardware, even by malicious software running on the device. To authenticate, the user must physically possess the device and pass its biometric or PIN verification — proving both possession and identity simultaneously.

## Registration and authentication flows

**Registration** creates the passkey credential and binds it to the user's SocketFi wallet:

```text theme={null}
1. User initiates wallet creation
2. SocketFi issues a registration challenge
3. User's device generates a new key pair in secure hardware
4. Device presents biometric or PIN prompt to the user
5. User authenticates on-device (Face ID, Touch ID, PIN, etc.)
6. Device signs the registration data with the new private key
7. Public key + signed challenge returned to SocketFi
8. Public key registered as the wallet's authentication credential
```

**Authentication** proves wallet ownership without transmitting any secret:

```text theme={null}
1. User initiates a transaction or sign-in
2. SocketFi issues a unique challenge
3. User's device locates the matching credential
4. Device presents biometric or PIN prompt to the user
5. User authenticates on-device
6. Device signs the challenge with the stored private key
7. Signed challenge returned to SocketFi
8. SocketFi verifies signature against the registered public key
9. Authentication succeeds — wallet authorization proceeds
```

Each challenge is unique and single-use. Capturing a response from one authentication session is useless for any future session.

## Security properties

### Phishing resistance

Passkey credentials are **origin-bound** — they are registered to a specific domain (e.g., `app.yourapp.com`) and will only respond to authentication requests from that exact origin. A fake phishing site at `app-yourapp.com` cannot invoke the user's passkey for `app.yourapp.com`, because the credential is cryptographically tied to the legitimate origin.

Compare this to passwords, which users can type into any website that asks for them.

### Credential theft resistance

Because the private key never leaves the device, there is nothing to steal from a server-side breach. An attacker who compromises SocketFi's backend gains only public keys — the private keys required to authenticate remain locked in secure hardware on users' devices.

### Replay attack protection

Every authentication challenge is unique and single-use. If an attacker intercepts a signed challenge response, they cannot reuse it for a second authentication — the next challenge will be different, and the old signature won't verify against it. This is combined with SocketFi's transaction-level nonce system for double-layered replay protection.

## Passkeys vs. passwords

| Security property            | Passwords                          | Passkeys                                     |
| ---------------------------- | ---------------------------------- | -------------------------------------------- |
| Phishing resistance          | ✗ — can be entered on fake sites   | ✓ — origin-bound, won't work on wrong domain |
| Shared secret                | ✓ — password must reach the server | ✗ — only a signature is transmitted          |
| Server-side breach risk      | High — hashes can be cracked       | None — only public keys stored               |
| Credential theft             | Possible — keyloggers, phishing    | Not possible — key never leaves device       |
| Device-bound protection      | Limited                            | ✓ — requires physical device possession      |
| User memorization            | Required                           | Not required                                 |
| Cryptographic authentication | Limited                            | ✓ — full asymmetric cryptography             |

## Passkey wallets vs. seed phrase wallets

| Property                     | Seed phrase wallet                          | SocketFi passkey wallet                           |
| ---------------------------- | ------------------------------------------- | ------------------------------------------------- |
| Secret to protect            | 12–24 word seed phrase                      | Private key in device secure hardware             |
| Backup required              | Yes — manual, risky                         | No — device sync or recovery flow                 |
| Backup complexity            | High — must be stored securely              | Low — handled by platform or recovery             |
| Phishing risk                | High — phrases can be entered on fake sites | Low — passkeys are origin-bound                   |
| Recovery on device loss      | Import seed phrase manually                 | SocketFi recovery flow — wallet address preserved |
| Everyday usability           | Lower — requires managing secrets           | Higher — biometric tap to authenticate            |
| Technical knowledge required | High                                        | Minimal                                           |

<Note>
  SocketFi's passkey model doesn't eliminate the need for recovery planning — device loss is still a scenario users need to prepare for. However, recovery replaces the passkey credential without changing the wallet address, meaning users never lose their on-chain identity or assets even if a device is lost.
</Note>

## What SocketFi stores

SocketFi stores only the **public key** associated with each passkey credential. SocketFi has no access to:

* The user's private key (stored in device secure hardware)
* The user's biometric data (processed locally by the device)
* The user's device PIN

This means SocketFi cannot authenticate on a user's behalf, cannot sign transactions without the user's device, and cannot access user funds — by design.