Encryption happens in the open-source client; the server only sees ciphertext. Secret values, encryption keys and your recovery phrase never reach us.
Visibility
Metadata is needed to run the service. Everything that could reveal a value stays on your devices.
Visible to StoreEnv
- Your username, email and avatar
- Project, service and environment names
- Key names (needed for templates, diffs and search)
- Value sizes, padded to 32-byte buckets
- Version messages and who changed what
- Who has access to what
- IP and device details for security
Never visible to StoreEnv
- Secret values
- The key of any secret
- Private keys
- Your recovery phrase
Template descriptions and examples are plain text that a project owner chooses to publish.
Encryption
All of this happens in the CLI or in your browser. The stored record carries an algorithm label, so stronger schemes can be added later without migrating data.
- 01
A fresh key per secret
A random 256-bit key is made for each KEY=value line.
- 02
AES-256-GCM
The value is sealed with a random 96-bit nonce. The auth tag detects any tampering, and decryption fails closed.
- 03
Labelled and sealed
Project, environment, service, key name and revision are authenticated with the ciphertext, so editing the ciphertext or its label makes decryption fail.
- 04
Wrapped per reader
The secret's key is wrapped to the public key of every member allowed to read it: one-time X25519, HKDF-SHA-256, then AES-256-GCM.
Identity
Signing in, with your email and password or a sign in method you connect, proves who you are to the API. Decrypting needs something else: a key pair derived from a 24-word recovery phrase that is generated on your device. The same phrase gives the same key pair everywhere. A new device gets the key from the phrase, or from a device you already use, sealed to a one-time key and confirmed with a short code.
We can't recover your data without your recovery phrase. If you lose the phrase and every device, teammates can share project secrets with a new identity, but secrets only you could read are gone.
06 scenarios
What an attacker gets in each case, stated plainly.
-
The attacker gets ciphertext, wrapped keys, public keys and metadata. Reading a value still needs a member's private key.
-
A server still can't read values. It could hand out a wrong public key to capture new shares, which the signed key log and fingerprint checks are there to catch. Every value and version is signed by the device that wrote it, and your CLI and browser check those signatures, the writer's devices in the key log and that you trust the writer before using a value, so a value the server made up is refused. A server could still show you a different key log than your teammates see; compare it with storeenv verify --head. Values written by older clients are marked unverified until a writer signs them.
-
The thief can call the API as you and receives ciphertext. Tokens are short-lived, and you can remove devices and sessions.
-
The private key is encrypted at rest behind the OS keychain. Remove the device, then re-key.
-
Re-keying stops future access through StoreEnv. Anything they copied is only safe again after you rotate it at the provider. We say so in the product.
-
CLI logins use a single-use state, localhost-only callbacks and a one-time exchange code. Tokens never travel in a URL.
Not yet independently reviewed. The open-source client (storeenv-cli and @storeenv/core, Apache-2.0) is there for anyone to read, and an independent cryptographic review is planned before general availability. The known limits are listed in the docs: Signed writes and the key log.
Found a vulnerability?
Write to us. We reply to every report.