What we can see, and what we cannot.

This page is written to be checkable rather than reassuring. Where a claim rests on arithmetic we say so; where it rests on us behaving well, we say that too — because a security page that does not distinguish between the two is marketing.

The short version

Secrets are encrypted in your browser under a key that is split across your key holders. We store ciphertext and a set of shares that are each encrypted to an individual’s public key. We hold no key that reconstructs anything. A complete dump of our database yields no secret material — an attacker would additionally need a quorum of your team’s passwords.

How a secret is protected

  1. Your browser generates a random 256-bit key and encrypts the payload with AES-256-GCM.
  2. That key is split using Shamir’s Secret Sharing into one share per holder, with a threshold K that you choose. Any K shares reconstruct it; any K−1 reveal nothing — not “nothing practical”, but nothing: every possible key remains equally consistent with what an attacker holds.
  3. Each share is encrypted to one holder’s public key (ECDH P-256 → HKDF → AES-256-GCM) and sent to us. We see only opaque blobs.
  4. To open it, a holder requests access with a stated reason. Each approver’s browser decrypts their own share and re-encrypts it to the requester. The plaintext share exists only in an approver’s tab, for milliseconds.

Your private key never reaches us in usable form: it is sealed with a key derived from your password via PBKDF2-SHA512 at 600,000 iterations, in your browser, and we store only the sealed blob so you can sign in from a second device.

Limits, stated plainly

If you forget your password, your key shares are gone

There is no recovery, because a recovery path we control would be a backdoor we control. This is survivable by design: every team secret needs a quorum, so the remaining holders re-key it and carry on. It is also why we refuse to let a secret be configured so that every single holder must be present.

We can see metadata

Titles, descriptions and tags are stored in the clear so the vault is searchable and so an auditor can see what exists without seeing its value. Do not put a password in a title. We also see who holds shares, who requested what and when, and the reasons given — that is the audit log, and it is the point.

Your browser is in scope

Client-side encryption means the client does the encrypting. A compromised browser, a malicious extension with access to the page, or a device with a keylogger defeats this — as it defeats every password manager. We serve a strict Content-Security-Policy and no third-party scripts on authenticated pages, which reduces our ability to attack you but cannot fix a compromised endpoint.

Message contents are not end-to-end encrypted

An emergency alert has to be delivered by email, SMS and voice to people with no account and no keys, so its body passes through our servers and through carriers in readable form. Treat alert text as you would a phone call. Secrets are never included in a notification — release messages carry a link and a code on separate channels, and neither one alone opens anything.

Operational security

Access to your account

Administrative access is not cryptographic access. An organisation owner can manage every team and read every audit log, and still cannot read a single secret without being a holder and gathering a quorum. Our staff have no elevated path at all.

Authentication

Passwords are hashed with scrypt. TOTP two-factor is available on every plan, and the seed is itself encrypted at rest. Failed sign-ins are rate-limited per IP, per address and per account, with the account lock enforced in the database rather than in process memory.

Delivery is confirmed, not assumed

A provider accepting a message records ACCEPTED, never “sent”. Only a provider webhook promotes it to DELIVERED. Anything that sits unconfirmed too long raises an alert, because a notification system that silently fails looks exactly like a quiet week.

Audit logs are append-only

There is no update path and no per-row delete path in the application. Only retention pruning removes anything, and it drops whole time windows rather than individual events. An audit log a customer can edit is worth nothing to their auditor.

Reporting a vulnerability

Email security@breakglass.business. We will acknowledge within one business day. We do not currently run a paid bounty, and we would rather say so than imply one exists. See Trust & compliance for framework mappings and sub-processors.