Browse the docs
Security model
What the server sees
Exactly what a Crunu server stores and learns: ciphertext, public keys, token HMACs, signed documents and metadata such as names, emails and the audit log.
Last updated
On this page
The Crunu server is blind to your values, but it isn't blind to everything. This page lists what it stores, what it learns from requests, and what it never gets. The same holds for app.crunu.com and for a server you host yourself.
What the server stores
| What | In what form | Can the server read it |
|---|---|---|
| Values of variables and files in environments | ciphertext | no |
| Environment keys | sealed to each recipient's public key | no |
| Your keyset | encrypted with a key derived from your password and Secret Key | no |
| Organization keys | sealed to the keysets of owners and admins | no |
| Public keys of people, devices, machines and service tokens | plain | yes, they're public |
| Session, invitation, enrollment-code and share-link tokens | only their HMAC, keyed with SERVER_KEY | it can check a token, not recreate it |
| Service tokens | only their public keys | no, it can't recover a token |
| Signed documents: certificates, access lists, revocation lists, access profiles, network rules | plain, with signatures | yes, but it can't change them unnoticed |
| Metadata | plain | yes |
The metadata the server can see
Metadata is visible to the server by design. It includes:
- the names of organizations, projects, environments, machines and access profiles;
- email addresses and names of people;
- who is a member of which organization, and their roles;
- the audit log: sign-ins, devices, invitations, role changes, versions, rotations, machines, tokens, share links, denials and network rule changes;
- the sizes and times of versions;
- which versions of which environment were delivered to whom, when, how often and from which address. This delivery record is what the exposure report is built from;
- network rules, address lists and the address of each request.
Names of environments and projects are signed inside the access list, so the server can't change them unnoticed. But it can read them. Don't name a project or environment so that the name itself is a secret.
Sizes are blurred a little: contents are padded to a multiple of 4,096 bytes before encryption.
What the server never gets
- Your password and Secret Key. They aren't sent over the network in any form. Sign-in works by signing a one-time challenge with a key derived from them on your device.
- Any decryption key. Environment keys reach the server only sealed to recipients' public keys.
- Values you reveal, copy or export. The web app records that you did it, signed by you and marked as client-reported, but the value itself isn't sent.
- The key of a share link. It lives in the part of the link after
#, which browsers never send to the server. - A full service token. It's created in the admin's browser and shown once. The server receives only its public keys.
Because the server never knows values, they can't end up in the audit log or in alerts.
What a stolen database gives away
Someone with a full copy of the database gets the ciphertext, public keys, token HMACs, signed documents and metadata. They can't:
- guess passwords, because each guess would also need the Secret Key, about 128.8 bits that never reach the server;
- replay tokens, because only HMACs are stored, keyed with
SERVER_KEY, which isn't in the database; - decrypt any environment.
They do learn the metadata: names, the team, how often things change.
What a compromised server could do
If someone controls the server's code and database, they get everything above, and they can answer requests however they like. Still:
- It can't add itself as a recipient. Environment keys are sealed only to keys certified by the organization signing key, and who gets what is decided by an access list that an owner or admin signed.
- It can't swap an environment key or a version. The access list commits to the key, and authors sign their versions.
- It can't quietly roll state back on a device that has already seen the newer state.
- It can't swap the keys of someone you invite or a machine you enroll, because the secret in the invitation link or enrollment code never passes through the server, and fingerprints are compared by people.
It can refuse service, lose records, ignore server-side rules such as network restrictions, and serve a tampered web app to people who sign in through it. Those risks and what to do about them are in Limitations.
Encrypted in transit as well
All traffic to the server goes over HTTPS. Even so, a tampered TLS connection or a malicious proxy would see only what the server sees for that connection. The password and Secret Key aren't sent at all, and each sign-in signature is tied to the server address and a one-time challenge.
Self-hosted servers
If you host your own server, its operator sees what this page lists, and so does anyone with access to the hosting account or a database backup. Backups contain no plaintext values, but they do contain the metadata. See Backups and restore.