Security

Security is foundational to Surface Security's design. This page covers the platform's security guarantees, encryption architecture, and compliance features.

Security Principles

Surface Security enforces the following security rules at every layer of the platform:

1. Passwords never leave the endpoint — All credential fingerprinting uses HMAC-SHA256 with device-specific secrets stored in the OS keychain. Only metadata about authentication events is transmitted. Actual passwords are never captured, transmitted, or stored.

2. End-to-end encryption with mutual TLS — Every request from the browser extension is encrypted at the application layer (AES-256-GCM) and signed (ECDSA), then transmitted over a mutually authenticated TLS channel. Two independent layers protect data in transit.

3. Tenant isolation at the database level — PostgreSQL row-level security (RLS) enforces strict tenant boundaries directly in the database, preventing any cross-tenant data access regardless of application-layer bugs.

4. Role-based access control — Administrative access is governed by granular roles: Super Admin, Admin, Analyst, Executive, and Viewer (5 roles total). Each role has specific permissions controlling what data can be viewed and what actions can be taken.

5. Complete audit trail — Every administrative action is logged with the actor, action, affected resource, and timestamp. The audit log is immutable and available for compliance review.

6. License validation on every request — Tenant license keys are validated on every API request, ensuring only authorized organizations can use the platform.

7. Gateway-level rate limiting — The Envoy gateway enforces per-client rate limits to protect against abuse and denial-of-service attacks.

8. Sensitive domain filtering — Banking, healthcare, and other sensitive domain categories are automatically excluded from telemetry collection.

9. Per-device certificate management — Each browser extension instance receives its own ECDSA certificate for request signing, with full revocation support. Compromised devices can be immediately cut off.

10. Time-limited enrollment — Device enrollment tokens expire after 7 days, limiting the window for unauthorized device registration.

End-to-End Encryption

Surface Security uses application-layer end-to-end encryption between browser extensions and the backend, operating in addition to transport-layer mTLS for defense-in-depth.

How It Works

Layer	Algorithm	Purpose
Key Agreement	ECDH (P-256)	Derive shared secret between extension and server
Key Derivation	HKDF-SHA256	Generate separate encryption keys for request and response
Body Encryption	AES-256-GCM	Encrypt request and response payloads
Request Signing	ECDSA-P256-SHA256	Authenticate the sender of each request

Each request generates a fresh ephemeral key pair, meaning that compromising one request's key material does not affect any other request. If E2E encryption is enabled and a cryptographic operation fails, the request is blocked entirely — it is never sent in plaintext.

Key Material

Key	Lifetime	Storage
Device signing key (ECDSA)	Until device is revoked	OS-level browser storage
Server channel key (ECDH)	Until rotated by admin	Server-side, encrypted at rest
Ephemeral request key	Single request only	In-memory, never persisted
Derived AES keys	Single request only	In-memory, never persisted

Breach Detection (HIBP)

Surface Security integrates with the Have I Been Pwned (HIBP) database to detect compromised credentials:

• Uses k-anonymity — only a 5-character SHA-1 prefix is sent to the HIBP API, so no full password hashes leave the endpoint
• Only the breach count bucket is stored (e.g., "100K-1M"), not the actual hash
• HIBP checking can be enabled or disabled per-tenant through the admin dashboard
• Employees are alerted immediately when a compromised password is detected

Data Retention

• Event data retention is configurable per-tenant (default: 90 days)
• ClickHouse TTL policies automatically expire old telemetry data
• Backup metadata is tracked for recovery and compliance purposes
• Retention periods can be adjusted to meet your organization's compliance requirements

Verification Codes

Surface Security provides a secure verification code system for identity validation, supporting two modes:

Daily Verification Codes

Time-based codes that change automatically each day:

• Cryptographically derived from the device secret and current date using HMAC-SHA256
• 6-digit numeric format for easy entry
• Automatically invalidated after the 24-hour window
• Device-bound — cannot be generated without access to the device secret

One-Time Passwords (OTP)

Single-use codes for high-security operations:

• Hashed with Argon2id (memory-hard, resistant to GPU/ASIC attacks)
• Immediately invalidated after use — no replay attacks
• Rate-limited to 5 attempts per code, 10 attempts per target per hour
• Configurable expiration window (default: 10 minutes, maximum: 30 minutes)

Verification Audit Trail

All verification events are logged for compliance and security monitoring:

Event	Data Captured
Code generated	Timestamp, device ID, code type, expiration
Code verified	Timestamp, device ID, success/failure, attempt count
Code expired	Timestamp, device ID, code type
Rate limit triggered	Timestamp, device ID, attempt count, lockout duration

Verification audit logs are stored in the analytics database and can be forwarded to your SIEM via the log forwarding integration.

SIEM Log Forwarding

Security events can be forwarded to your existing SIEM platform for centralized monitoring. Supported destinations:

Destination	Protocol	Format
Splunk HEC	HTTPS	JSON
Webhook	HTTPS	JSON
Syslog	TCP/UDP/TLS	RFC 5424
Elasticsearch	HTTPS	JSON (Bulk API)
Amazon S3	HTTPS	JSON

Forwarded events include severity levels (Critical, High, Warning, Info) and cover verification events, security alerts, credential activity, authentication flows, and administrative actions.

Production Security Checklist

Before deploying Surface Security to production, verify the following:

Licensing

• License key configured and verified on startup
• License expiration date is in the future
• Development mode is disabled

Infrastructure

• All default passwords changed
• mTLS certificates generated and deployed
• Secrets stored in a secrets manager (not hardcoded)
• Network policies configured
• Backup encryption enabled
• Audit logging enabled
• Rate limiting configured
• CORS origins restricted to your domains
• Browser extension published privately (not to public store)
• Update bundle signature verification enabled
• Rollback procedures tested and verified
• Native companion app code signing verified (if applicable)

Enterprise Integration (if using SCIM / MDM)

• SCIM OAuth client secrets rotated on a regular schedule
• Native messaging host binary is code-signed (Windows) or notarized (macOS)
• Managed storage policies configured as read-only
• mTLS CA certificate uploaded in platform settings
• Certificate encryption key securely stored and backed up

Database Security

• Row-level security (RLS) policies active on all tenant-scoped tables
• Force row-level security enabled so policies apply to all roles
• Database credentials rotated and stored securely