Security

Break Glass

Your emergency plans are encrypted at rest with keys unique to your account. Here's how we protect your data.

Encryption Architecture

Every piece of sensitive data is encrypted before it's written to the database.

Message content

Encrypted with AES-256-GCM envelope encryption. Each message gets its own random encryption key, wrapped with a key unique to your account. Your information is stored as ciphertext that cannot be read without your account's key.

Contact details (names, emails, phones)

Encrypted at the field level with a per-user key. Email lookups use blind indexes so we can search encrypted records without decrypting them.

PINs and passwords

Hashed with Argon2id, the current gold standard for password hashing. PINs and passwords are never stored — only their irreversible hashes. Argon2id is resistant to GPU and ASIC brute-force attacks.

Activation tokens

Hashed before storage. The raw token is shown once when created and never stored or retrievable.

Per-user isolation: Each user's encryption keys are derived independently. One user's keys cannot decrypt another user's data.

How Key Management Works

Passwords and PINs are irreversibly hashed — we store only the hash and can never recover the original.
Activation tokens are hashed before storage — the raw token is shown once and never stored.
Each user gets unique encryption keys. One user's keys cannot decrypt another user's data.
The master key is protected by hardware security — if the server is physically stolen, your data cannot be decrypted.

When your safety check-in activates or a trusted contact activates your plan, the server decrypts your messages and delivers them to the people you designated. This is how Break Glass can deliver your information when you're unable to act yourself.

We protect this capability with multiple layers of infrastructure hardening: full-disk encryption, hardware-backed key protection, strict access controls, and tamper-detectable audit logging.

Infrastructure

Self-hosted on dedicated hardware — not shared cloud infrastructure.

Disk encryption	Full-disk encryption at rest. All data including swap is encrypted.
Key protection	Hardware-backed key protection. The master key cannot be extracted if the server is physically removed.
TLS	TLS 1.2+ only (legacy versions disabled). SSL Labs A+ rated. HSTS enabled.
Network	Reverse tunnel ingress — no public ports exposed on the origin server. Traffic filtered through enterprise-grade DDoS and WAF protection.
Security headers	Strict Content Security Policy, Permissions-Policy, X-Frame-Options, Referrer-Policy, X-Content-Type-Options.
Logging	Structured logging with automatic redaction of sensitive data. PII, encryption keys, tokens, and passwords never appear in logs.
Database	Internal network only — not exposed to the host or internet.

Authentication & Access Control

Password hashing	Argon2id with tuned parameters. Passwords are never stored — only irreversible hashes.
Two-factor auth	TOTP (time-based one-time passwords) with backup codes.
Session management	httpOnly, Secure, SameSite=Lax cookies. Sessions are cryptographically signed.
Brute-force protection	Rate limiting and progressive lockout on authentication and activation attempts.
Activation security	Two-factor channel separation: activation URL delivered via email, PIN shared out-of-band (in person, phone call, separate app). Compromise of one channel is insufficient.
Multiple approvals	Optional requirement for multiple trusted contacts to independently approve before a plan activates. No single person can trigger alone.

Audit Trail

Every significant action is recorded in an append-only audit log with cryptographic chaining. Each entry's integrity hash incorporates the previous entry, creating a tamper-detectable chain — if any entry is modified or deleted, the chain breaks and the tampering is visible.

The audit log records: activation attempts, PIN verification results, scenario activations, settings changes, login events, and notification delivery outcomes. All entries are scoped per user — you can only see your own audit history.

Responsible Disclosure

If you discover a security vulnerability, please report it to [email protected]. We commit to acknowledging reports within 48 hours and providing a fix timeline within 7 days.

Our security.txt file provides machine-readable contact information per RFC 9116.

We do not currently offer monetary bounties, but we credit all researchers who report valid vulnerabilities in our security acknowledgments.

Threat Model

For security researchers and technical evaluators.

Physical theft — Full-disk encryption with hardware-backed key. Server disk is unreadable if removed.
Database leak — All sensitive data is encrypted at rest. A database dump contains only ciphertext.
Network interception — TLS 1.2+ with HSTS. No legacy protocol support.
Cross-user data access — Per-user encryption keys with tenant isolation at the query level.
Brute force — Rate limiting, progressive lockout, and memory-hard password hashing.
Accidental activation — Configurable cancellation windows with instant multi-channel notification.
Single-point-of-failure activation — Multiple-approval mode requires multiple people to agree.
Audit tampering — Cryptographically chained log detects modification or deletion.

Break Glass uses server-side key management to enable automated emergency delivery. The safety check-in must be able to decrypt and deliver your information when you can't act yourself — this requires the server to hold decryption capability.

We mitigate this with defense in depth: full-disk encryption, hardware-backed key protection, per-user key derivation, strict access controls, and tamper-detectable audit logging. This is the same server-side key management model used by major cloud services that offer automated processing of encrypted data.

For maximum security, store instructions for WHERE to find sensitive credentials (e.g., "the seed phrase is in the fireproof safe, combination is...") rather than the credentials themselves. Break Glass is designed as an emergency instructions delivery system.

Enable two-factor authentication on your Break Glass account.
Distribute PINs out-of-band — in person, phone call, or a separate secure app. Never send PINs via email.
Require multiple approvals for high-value scenarios — require multiple people to agree before your plan activates.
Review your plan regularly — Break Glass sends periodic review reminders to keep your information current.
Store instructions, not sensitive information — for crypto seed phrases, master passwords, and private keys, store where to FIND them rather than the credentials themselves. "The backup is in the fireproof safe" is safer than the seed phrase itself.