How KeyValt keeps your portals private

Principles

• Zero-knowledge storage. The server stores encrypted blobs and the metadata needed to sync them. It never receives your master password, vault key or decrypted credentials.
• Least privilege. The extension requests access only to the websites you save, and administrators can manage accounts without any path to vault contents.
• Fail closed. If a domain, signature, permission or key check fails, KeyValt does not fill.
• No dark patterns. We never bypass CAPTCHAs, SMS OTPs or security checks on the portals you use.

Vault encryption

When you create your vault, your browser generates a random 256-bit vault key. Your master password is stretched with Argon2id (64 MiB memory, 3 iterations, 4 lanes by default) into a master key, from which two independent keys are derived with HKDF-SHA-256:

• an encryption key that wraps your vault key, and
• an authentication proof that is sent to the server to sign in. The server hashes it again with scrypt and a per-user salt, so a database leak doesn’t reveal anything that unlocks your vault.

Every portal, account and note gets its own random item key. Item data is encrypted with AES-256-GCM using a fresh 96-bit nonce per encryption and additional authenticated data that binds each ciphertext to its purpose. Item keys are wrapped by your vault key (or a team collection key). Everything uses the browser’s native Web Crypto API.

Encrypted on your device: portal names, website addresses and allowed domains, usernames, passwords, authenticator secrets, notes, custom fields, labels and categories. The server sees only what it needs to operate: item type, timestamps, revision numbers, item counts, favourite/usage flags that you set and — for portals added from the public directory — which directory entry they came from.

Authentication

• Sign-in uses the derived authentication proof, never the master password. Unknown emails receive deterministic decoy parameters so accounts can’t be enumerated.
• Sessions are random 256-bit tokens stored as SHA-256 hashes, sent in HttpOnly, Secure, SameSite=Lax cookies, with idle and absolute expiry. State-changing requests require a same-origin check.
• Two-step sign-in with authenticator apps (TOTP) and one-time recovery codes, with replay protection. Staff use a separate admin sign-in that always requires a second factor.
• Rate limits and progressive lockouts on sign-in, recovery and pairing endpoints, with email alerts for new devices.

Domain-verified autofill

The websites a login may be filled on are stored inside the encrypted item, so even a compromised server can’t silently change where your password goes. Before filling, the extension:

1. reads the frame’s real origin from the browser (not from the page’s own claims),
2. requires an exact scheme + host + port match, or a subdomain match only if you explicitly allowed it,
3. never fills on HTTP (except local development), on IP-address look-alikes, or into hidden fields,
4. warns about look-alike domains such as gst-gov-login.com or gst.gov.in.evil.com, and
5. refuses to auto-submit if a CAPTCHA is present or if the form would post to a different website.

Extension security

• Manifest V3 with a strict content security policy — no remote code, no eval.
• Paired with your account through a one-time code that you approve in the dashboard; each extension gets its own revocable device token, rotated regularly.
• Unlocked keys live only in the browser’s in-memory session storage and are cleared on lock, idle timeout or browser restart. Offline data is stored encrypted.
• Messages from web pages are validated strictly and accepted only from the KeyValt web app’s origin.
• Portal configurations (field selectors for known portals) are signed with ECDSA P-256 and verified in the extension with rollback protection. They can only describe how to fill — never where to send your credentials.

Team sharing

Organizations use RSA-OAEP-3072 key pairs per member to share collection keys end-to-end. Owners confirm new members by comparing key fingerprints. Use-only access lets staff fill a login without the KeyValt apps ever revealing, copying or exporting the password. This is an application-level control: a determined technical user with access to their own browser could still extract a password that was filled into a page. Rotate passwords when someone leaves.

Account recovery

There is no master-password “reset” that preserves your data without a key you hold — that would be a backdoor. Instead, you create a recovery kit containing a recovery key (it starts with KVRK-) that independently unlocks your vault key. If you lose both your master password and recovery key, you can reset your account, which permanently deletes the encrypted vault.

Infrastructure

• TLS everywhere with HSTS, a nonce-based Content Security Policy, frame-ancestors restrictions and strict security headers.
• Payment card data is handled entirely by Razorpay; KeyValt never sees card numbers. Webhooks are verified with HMAC-SHA256 signatures and processed idempotently.
• Audit logs and security events record sign-ins, device approvals, sharing changes and admin actions — never secrets.
• Server-side secrets (such as authenticator secrets for your KeyValt account) are encrypted with a separate key-encryption key.

What we can’t protect against

No product is perfectly secure, and we won’t claim otherwise. KeyValt cannot protect you if your device is compromised by malware or a malicious browser extension, if someone learns your master password, or if a portal itself is breached. A weak master password weakens all of the above — which is why we require a strong one.

Reporting a vulnerability

We welcome reports from security researchers. Please read our vulnerability disclosure policy, or continue with the encryption guide.