A vault you can reason about, including where it stops

Questions you'll be asked

Most security work on secrets is answering questions. Who can read production? Who actually did? What would a breach of the hosting expose? What changed after someone left?

The job is to have those answers in a form you can show to an auditor, a customer or your board.

What you can say, and why it holds

• The server can't read values. Encryption happens only in the browser and in the crunu agent. The server stores ciphertext, public keys and signed documents, and has no decryption key at any point in the protocol.
• A stolen database doesn't open values. The account key is derived with PBKDF2-SHA256 over 1,000,000 iterations from the password and a Secret Key of about 128 bits, and neither reaches the server. A full copy of the database is useless for guessing.
• The server can't grant itself access. Access lists and every version are signed. Clients and agents check the signatures and reject states older than the newest they've seen. A device that never saw the newer state can't detect a rollback.
• Roles are enforced by keys. A member with development access has no production key. An Operator enrolls machines without seeing any values.
• The log shows tampering. The audit log is a hash chain: editing, deleting or inserting an entry shows up when you verify it. Verify in one click, or export JSONL and check it outside Crunu.
• Showing and copying are logged too. When someone reveals, copies or exports a value, the event is recorded with their signature and marked as reported by the client.
• Departures leave a record. Member removal produces an exposure report: which versions of which environments the person received, when and from which address.
• You can check the client you run. Releases are signed with Ed25519, the web client builds reproducibly, and the app checks its own build against the signed release on every load.
• Sign-in is rate-limited. 10 failed attempts per address and 5 per account in 15 minutes, and "no account" looks the same as "wrong password". A session lasts 12 hours idle and 7 days at most, and can't change the password or delete the account without the password and Secret Key.
• Second factors on every account. Authenticator app codes and passkeys on the web; in the terminal, an app code or approval from another signed-in device.

Algorithms: AES-256-GCM for values, X25519 for sealing keys, Ed25519 for signatures, HKDF-SHA256 for key derivation. The security model explains how they fit together.

When something looks wrong

• Alerts fire on sign-ins from a new device, a reused enrollment code, a machine on a new address, a replayed CI token, a run of denials, an expired lease, a recovery-code sign-in, expiring certificates, undelivered keys, and network events such as a relaxed policy or break-glass access. They go to a webhook signed with HMAC or to email.
• Network restrictions serve production only to allowed address ranges. Relaxing a policy waits 15 minutes with an alert and an undo; break-glass access by an owner lasts up to 60 minutes, needs a reason and raises an alert.
• Device compromised replaces the person's account keys, signs out their other devices and rotates every environment they held a key for.
• Retention you control. The audit log is kept 365 days by default, and the organization can only extend it, up to 36,500 days or indefinitely. Trimming keeps a checkpoint, so the chain still verifies.

What Crunu can't protect

• A tampered web client is the main remaining risk, as with any vault that runs in a browser: a page served by a compromised server could capture the password and Secret Key at sign-in. The defenses are the signed manifest the app checks itself against on every load, and a content security policy with subresource integrity that blocks third-party scripts. That self-check runs in the same page, so it can’t catch a server that changes both. Signatures rely on the release key, so they don't protect you from whoever holds that key.
• Values already seen can't be taken back. Rotation protects new versions. Reissue the values themselves at each provider.
• The server sees metadata: names of organizations, projects, environments and machines, email addresses, the audit log, and the sizes and times of versions.
• The server can refuse service or drop writes. Exports, offline copies and, if you self-host, backups are the defense.
• Malware on a device where keys are decrypted (a keylogger, a browser extension, root on a machine) can read what that device can read.
• A recovery code opens an account after a waiting period without a second factor. The wait is enforced by the server, so a compromised server could skip it.
• Network restrictions are enforced by the server, not by encryption.
• Owners and admins can reach every shared environment through the organization recovery key.
• A compromised server working with a removed member could hold a new device on an older state of the organization. Closing this completely would need an external transparency log.
• If the server's database and its own key leak together, authenticator app codes are weakened as a second factor.
• No single sign-on or SCIM.

Each limit, with what to do about it, is on the limitations page.

Found something?

Write to security@crunu.com. Our security.txt is at /.well-known/security.txt.

Related docs

• How encryption works
• What the server sees
• Limitations
• Audit log
• Alerts
• Network rules
• Offboarding a teammate