TATER Vault

Zero-knowledge by design

Every secret you store is encrypted client-side with AES-256-GCM under a key derived from your master passphrase. The server never sees your passphrase, your derived key, or any plaintext credential — only the resulting ciphertext and the wrapped key material required for recovery. This means:

• A server breach does not expose passwords. An attacker with full database access still sees only AES-GCM ciphertext and RSA-wrapped key blobs.
• TATER staff cannot read your vault. Support can see that items exist (counts, titles are also encrypted), but never their contents.
• Your master passphrase is unrecoverable by us. It is never transmitted. The organization escrow chain (below) is the only sanctioned recovery path, and it is admin-gated and audit-logged.

Getting started

1. Go to vault.tatersecurity.com and sign in with your normal TATER (Entra) identity.
2. On first use you set a master passphrase. Choose something long and memorable — a passphrase of several unrelated words beats a short complex string. This passphrase unlocks your vault on every device; it is separate from your Entra sign-in.
3. The vault key is wrapped and escrowed to your organization's key (see Organization ownership & escrow) so the org retains the ability to recover credentials when you leave. A per-user RSA keypair is generated for group sharing; your private key is itself AES-wrapped under your master passphrase.
4. Start adding logins — manually, by importing, or automatically via the browser extension.

Passkeys & unlock

Beyond the master passphrase, you can unlock your vault with a passkey — Touch ID, Windows Hello, or a hardware security key. Manage them from the Passkeys & unlock card on the Security dashboard:

• Add a passkey. Click + Add a passkey and follow your browser's prompt. Multiple passkeys can be registered (e.g. laptop biometric + a backup security key); each shows when it was added and last used, and can be removed individually.
• How it works. The passkey uses the WebAuthn PRF extension: your vault key is wrapped to the passkey, and the assertion output unwraps it locally. TATER never sees the key — the zero-knowledge boundary is unchanged. Phishing-resistant, nothing to remember.
• Require a passkey. Once you have at least one passkey, a Require a passkey to unlock my vault toggle makes the passkey mandatory (the remembered-device unlock is disabled). Otherwise the passkey is offered alongside the existing unlock paths.
• Passkey vs. TOTP. The built-in TOTP authenticator stores second-factor secrets for your other accounts; a passkey is how you unlock the vault itself.
• Recovery. If you lose your passkey, the "Can't use your passkey?" link on the unlock screen falls back to recovery via your organization's key escrow.

Storing logins, secrets & notes

Each vault item holds a title, username, password, URL, notes, an optional TOTP secret, and a password-change history. Items live in a personal vault by default, or in a shared vault. Everything in the encrypted envelope — including the title and notes — is encrypted before upload.

• Choosing where it goes. The Add/Edit dialog opens with a Vault selector at the top — pick your personal vault or any shared vault you can write to, so there's no ambiguity about where a new item is saved. The detail view shows the item's current vault (👤 My items or 👥 the shared vault).
• Moving between vaults. Change the Vault selector on an existing item and save — TATER re-encrypts the item to the destination vault's key (your personal key or the shared vault's key), writes it there, and removes the original. Everything happens in your browser; the server only ever sees ciphertext.
• Password history. When you change an item's password, the prior value is retained (up to 10 entries) inside the encrypted envelope, with the date it was replaced. Edit any other field and the history is carried forward intact.
• Copy / reveal. Passwords are masked by default; reveal or copy from the detail view.

Item version history & restore

Every edit to an item snapshots the prior version — still encrypted, so the server never sees the contents. Click 🕘 History on an item's detail view to open the version list:

• Timeline. Versions are listed newest-first with the change timestamp and, in shared vaults, who made the change.
• Preview. Decrypts a chosen snapshot in your browser and shows its fields inline — secrets stay masked with the usual Show / Copy controls.
• Restore. Brings a prior version back as the current value. The present state is itself saved as a new version first, so a restore is always undoable (a linear undo chain). Restore requires write access to the vault the item lives in — viewers can browse history but not restore.
• Version history works for personal-vault and shared-vault items alike, and complements the in-envelope password history above (which tracks only prior passwords).

Import & export

Move credentials into and out of TATER Vault without ever handing the server a plaintext secret. Every import is parsed and re-encrypted under your master passphrase in the browser before upload, and every export is assembled client-side from items you've already decrypted — the same zero-knowledge boundary applies in both directions.

Importing from another manager

The Import dialog reads an export file from your previous password manager (or a prior TATER backup), maps its fields to vault items, and lets you pick the destination vault before anything is saved:

• Supported sources. Keeper, 1Password, LastPass, and Bitwarden, plus a generic CSV mapper for anything else. Both the CSV and JSON exports those tools produce are accepted — titles, usernames, passwords, URLs, notes, and TOTP secrets are mapped onto vault items, with password history preserved where the source provides it.
• TATER encrypted backup. A .tater backup previously exported from TATER Vault re-imports directly. You supply the passphrase the backup was sealed with; it is unwrapped and re-encrypted under your current master passphrase in the browser.
• Choose the destination. Pick your personal vault or any shared vault you can write to from the Vault selector — the same selector used in the Add/Edit dialog — so imported items land exactly where you intend.
• Parsed in your browser. The import file is read and decrypted entirely client-side; the server only ever receives the resulting ciphertext. Delete the plaintext export file from your downloads once the import succeeds — those files are unencrypted by the originating tool.

Encrypted personal export

Export your own vault to a single passphrase-encrypted backup file that only you can reopen:

• Sealed under a passphrase you choose. The export is assembled from your decrypted items and re-encrypted with AES-256-GCM under a passphrase you set at export time (it can differ from your master passphrase). The file leaves your browser as ciphertext — TATER never sees the export passphrase or its contents.
• Re-importable. The resulting .tater file imports back into TATER Vault (see above) on any device, making it a portable, self-contained backup. Keep it somewhere safe — anyone with the file and the export passphrase can open it.
• Personal items only. Shared-vault items are excluded; export those from the shared vault itself if you have the rights.

Admin inventory export

From the vault governance surface (Admin), an organization administrator can export an inventory of enrolled vaults — counts of items, folders, shared-vault memberships, and enrollment status per user — for audit and offboarding-gap review.

• Metadata, not contents. The inventory export reports that items exist, never their plaintext. The zero-knowledge boundary holds: recovering an individual user's actual credentials is a separate, escrow-gated action covered under Offboarding a departed user.
• Gated & audited. Generating an inventory export requires admin rights and the per-org vaultEscrowEnabled setting, and the action is audit-logged at high severity so every export is attributable.

Built-in MFA / TOTP authenticator

TATER Vault is also an authenticator app. Paste an otpauth:// URI (or the raw base32 secret) onto any item and the detail view shows the live 6-digit code with a countdown ring — fully RFC 6238 compliant (SHA-1/256/512, configurable period and digits).

• The raw TOTP secret is stored encrypted alongside the password and is never displayed once saved — only the rotating code is shown.
• The browser extension surfaces the current code in its popup so you can copy it during a login without leaving the page.
• Keeping the password and its second factor in one zero-knowledge vault means a single unlock covers the whole login — convenient without weakening MFA, because the vault itself is the thing you protect.

Password & passphrase generator

Generate strong credentials inline on any item, or from the standalone generator:

• Random password — length slider, character-class toggles (upper / lower / digits / symbols), and an "avoid ambiguous characters" option to skip look-alikes like l/1/I and O/0.
• Passphrase — word-based generation from a curated list, for memorable-but-strong secrets.
• Live strength meter estimates entropy as you tune the options so you can see the trade-off immediately.

Security dashboard

The Security view audits your whole vault client-side and produces a vault-health score with actionable groups:

• Reused passwords — items grouped by identical password so you can rotate the riskiest ones first.
• Duplicate tracking — surfaces credentials shared across multiple sites.
• Weak passwords — low-entropy entries flagged for replacement.
• Missing 2FA — accounts with no TOTP secret stored that probably should have one.
• Stale credentials — passwords that haven't been rotated in a long time.
• Breach check (opt-in) — uses the Have I Been Pwned range API with k-anonymity: only the first 5 characters of a SHA-1 hash of the password ever leave the browser, so the full password is never exposed. Flags credentials known to appear in public breach corpora.

Group sharing (shared vaults)

Teams share credentials through shared vaults without ever exposing a plaintext key to the server. Each shared vault has a random AES-256 shared-vault key (SVK) that is wrapped to every member's public RSA key in the browser. Items in the vault are encrypted with the SVK.

• Roles. Owner / Editor / Viewer. Owners manage membership; Editors and above can write items; Viewers read only.
• Adding a member re-wraps the SVK to the new member's public key in your browser — the server only ever stores wrapped blobs.
• Removing a member re-wraps the SVK for the remaining members so the departed member's wrapped copy is no longer valid.
• Isolation. The API enforces that a caller is a member of the shared vault before any item operation, and that personal-vault queries never return shared items.

Organization ownership & escrow

TATER Vault follows the enterprise model: credentials belong to the organization and are leased to users. This is structural, not a toggle.

• Always escrowed. At enrollment, every user's vault key is wrapped to the organization's root key (held in the org's Key Vault) — enrollment requires this wrap. The org therefore always retains a recovery path.
• Membership-gated access = instant lease revocation. Vault API access is gated on active org membership. Remove a user from the org and their access ends immediately.
• Exercising ownership is separately gated and audited. A per-org vaultEscrowEnabled setting controls whether admins may exercise ownership (break-glass recovery + shared-vault takeover). It does not control whether keys are escrowed — they always are.

Offboarding a departed user

From TATER Security's vault governance surface (Admin), a departing or departed user can be handled in several ways:

• Recover — admin recovers the user's credentials via the escrow chain and exports them (personal items; shared items are excluded from the CSV). Requires only the admin's public key, so the admin doesn't need to unlock their own vault.
• Reassign — transition a departed employee's workload by moving their logins to another person's vault or into a shared group vault. In the isolated vault app the admin recovers the source user's key (escrow), decrypts the logins in that sandbox, and re-encrypts each one to the destination key — the recipient's own vault key (also escrow-recovered) or the group's shared key (SVK). No plaintext ever leaves the sandbox; the API only relocates ciphertext and removes the moved originals (optional). Logged at high severity.
• Take ownership of shared vaults — for any shared vault where the departing user was an owner, an admin can become owner with an SVK re-wrapped to their own public key. This grants nothing beyond the recovery power escrow already provides; it just makes it a first-class, governed flow.
• Purge — destroy the user's personal items, folders, and enrollment. Double-confirmed in the UI and logged at high severity.

The governance table flags users who are still enrolled in the vault but no longer in the organization (matched case-insensitively against both user id and email) so offboarding gaps are visible at a glance.

Emergency access (trusted peer)

Organization escrow (above) is the admin recovery path. Emergency access is the personal one: you nominate a trusted colleague who can reach your vault if you're ever unavailable — without involving an admin. Configure it from the Emergency access card on the Security dashboard:

• Nominate a contact. Pick any enrolled member of your organization and a waiting period — Immediately, 1 hour, 24 hours, 48 hours, 7 days, or 14 days. Your vault key is wrapped to the peer's RSA public key in your browser; the server stores only the wrapped blob and will not release it until access activates. Zero-knowledge holds throughout.
• The request flow. When your contact needs in, they click Request access. You're in the waiting period from that moment: you can Deny the request (or remove the contact) any time before it elapses, or Approve now to skip the wait. If the wait passes with no denial, access activates automatically.
• Read-only. An active emergency contact can decrypt and read your items but not change them. Their status card shows when access was last used, and you can revoke it at any point.
• How it differs from escrow. Escrow recovery is exercised by an admin through the governed offboarding flow; emergency access is delegated by you, to a peer you choose, with a self-serve timed grant. The nominated peer can also decline the role.

Browser extension

The TATER Vault browser extension (Manifest V3) captures logins as you sign in and fills saved credentials on return visits. It shares the exact same WebCrypto core as the web vault, so encryption is byte-identical across surfaces. The popup also shows the live TOTP code for the matched item so you can complete an MFA challenge inline. Current versions add an inline autofill glyph on recognized login fields (pick the credential right in the page), a save-on-new-login prompt when you sign in with a credential the vault doesn't have yet, and field discovery that pierces open shadow DOM and same-origin iframes so modern SPA login forms fill correctly.

Restricted Vault vs. password Vault

Don't confuse the two "vault" surfaces:

• TATER Vault (this document) is the zero-knowledge password manager for end users — logins, TOTP, generator, sharing. Served at vault.tatersecurity.com.
• Restricted Vault is an operational documentation surface for sensitive inventories (privileged-account rosters, network diagrams, asset lists) with per-document allowlists and audit-logged reads. Different feature, different purpose.

Compliance & hygiene

Because the org owns the vault and the Security dashboard computes reuse / weak / no-2FA / stale counts client-side, vault hygiene becomes a measurable signal. A planned enhancement rolls org-wide password-hygiene counts (computed client-side, never plaintext) into the compliance dashboard so password posture sits alongside the rest of your control coverage.

Last updated: 2026-07-22.