The keys to your vault

The SHTERA vault encrypts each folder with its own key (the DEK), wrapped several different ways: with the master password, with a 24-character recovery code handed out when the account is created, with a WebAuthn PRF-compatible passkey, and with a backup copy kept for the case of losing all three of those at once.

That backup copy (the rescue key) doesn’t live on this server: it lives encrypted on a small, separate machine, on another provider, that accepts no inbound connections from anyone. Recovering access with it requires verifying identity with a small charge to the card on file (between US$ 9 and US$ 10, with a code in the description) — without that confirmed charge, the rescue key is never touched. This isn’t a promise that nobody can open the vault under any circumstance: it’s the guarantee that opening it requires going through a separate, audited, verified mechanism, never a direct path from this server.

That guarantee depends on the code running in your browser being the code we say it is: like any service used from the web with nothing installed, it’s the server that delivers that code on every visit. SHTERA doesn’t hide this — it’s the same limit any zero-knowledge vault has when served this way, without a dedicated application installed on your machine.

The 24-character recovery code isn’t only handed out once at signup: it can also be saved encrypted inside the vault itself, with the account key, and read again later from its own Settings tab. Reading it that way takes more than an open session: it requires opening, in the same browser, the links from at least two of the three configured recovery emails — each link carries only part of the key, and one part alone reveals nothing.

The panel session is also configurable, beyond how it’s opened: each user picks how long it stays alive without activity —30 minutes, 1, 6, 12, or 24 hours— or that it never expires. Never expiring is a privilege of the place, not the person: it only turns on for an account that already has a trusted address loaded, and it only applies signing in from there. This is set alongside the trusted addresses, the app-based second factor, and passkeys, grouped into tabs inside Account Settings.