Skip to main content
Keyflare’s security architecture is designed around zero trust storage and minimal attack surface.

Threat Model

Security Boundaries

Key principle: Plaintext secrets exist ONLY in Worker memory during request processing. Never logged, never cached.

What Gets Encrypted

Encrypted (AES-256-GCM)

  • Secret values (DB_PASSWORD=hunter2)
  • Secret key names (DB_PASSWORD)
  • API key labels
  • System key scope definitions

NOT Encrypted (by design)

  • Row IDs (UUIDs — no information leakage)
  • Timestamps (created_at, updated_at)
  • Project names
  • Environment names
  • API key type (user / system)
  • API key permission level
  • Revocation status

API Key Security

Key Format

Examples:
The prefix makes key type identifiable and enables secret scanning tools to detect leaked keys.

Key Storage

Why SHA-256 and not Argon2id? API keys have 128 bits of entropy (vs ~40 bits for passwords), making brute-force infeasible regardless of hash speed. SHA-256 is fast, native, and adds zero dependencies.

Permission Levels

Master Key Management

Single Point of Failure

The master key is the single root of trust. If lost, all encrypted data is permanently unrecoverable. There is no backdoor.

Mitigations

  1. Managed by Cloudflare — Stored as Worker secret, encrypted at rest
  2. User backup required — Must save key in password manager or physical safe
  3. Clear warningskfl init prompts to confirm key was saved

Master Key Format

Example:

Generation

Or let kfl init generate one automatically.

Update Behavior

When running kfl init on an existing deployment:
  • Master key is NEVER changed — even if --master-key is provided
  • This prevents catastrophic data loss from accidental key rotation

Next Steps

Encryption Details

Deep dive into the crypto implementation.

API Keys

Learn how to create and manage API keys.