Password Manager — How It Works and What It Protects

The CalculatorAI Password Manager is a zero-knowledge vault: every login you save is encrypted in your browser with a key that only your master password (or your recovery code) can produce, and the server stores nothing else. This page explains what that means in practice — what leaves your device, what does not, what an attacker gets in each breach scenario, and where the limits are.

The one-sentence model

The server keeps ciphertext and wrapped keys. It never sees a password, a master password, a recovery code or a vault key.

A copy of the entire database — obtained by breaking in, by a leaked backup, by a rogue administrator — contains blobs that cannot be opened without a secret the database does not hold. That is the design, not a policy; there is no setting that turns it off and no support tool that reads around it.

What happens when you set it up

Your browser generates a random 256-bit vault key using the Web Crypto API.
Your master password is stretched with PBKDF2-SHA256 (600,000 rounds, a random per-vault salt) into a key-encryption key, which wraps the vault key with AES-256-GCM.
A recovery code — 32 characters from an unambiguous alphabet, 128 bits of entropy — is generated, stretched the same way, and wraps the same vault key a second time.
The two wrapped copies and the salt are sent to the server. The vault key, the master password and the recovery code are not.

Either secret can unwrap the vault key. That is why the recovery code works without the server, and why changing your master password never touches a single saved login: only the wrapper changes.

The title, username, password, website, notes and category are serialised together and encrypted with the vault key under AES-256-GCM with a fresh random 96-bit nonce. The server receives one opaque blob and two timestamps. There are no plaintext columns for any field — not the title, not the website. Search, filters and sorting run in your browser over the decrypted rows, so the server cannot learn what you are looking for either.

What happens when you unlock

Your master password is stretched again, the wrapped vault key is unwrapped, and every blob is decrypted in the tab. The vault key lives only in the page's memory: never in localStorage, sessionStorage, IndexedDB or a cookie, never in any request. A wrong master password fails inside the cipher's own authentication check — there is no separate "password hash" stored anywhere that could be attacked or leaked.

The vault locks itself: after the idle period you choose (1, 5, 15 or 60 minutes), when the tab has been in the background for more than a minute, when the page is left, and when you sign out. Locking discards the key and the decrypted rows.

What an attacker gets

Scenario	What they get
A copy of the database, backups included	Encrypted blobs and wrapped keys. Nothing to decrypt them with.
Your CalculatorAI account password, or a reset through your email	Access to the account, and to the same blobs. The vault asks for the master password — a separate secret the account login never sees.
A stolen session cookie from another tab or device	The same. If two-factor sign-in is on, the vault's tables are hidden from any session that has not passed the second factor.
A phishing page that captures your master password	This is the one that works — which is why two-factor sign-in and the auto-lock exist, and why the master password should never be reused anywhere.
Malware or a keylogger on your own device	No password manager on Earth protects against this. What you type and what is on your screen is visible to a compromised device.

Unlocking with a passkey (Face ID, Touch ID, a security key)

A passkey is the one unlock path that cannot be phished, and it is not a shortcut past the encryption. WebAuthn's PRF extension asks the authenticator to derive 32 bytes from a secret that never leaves the device; those bytes become the key that unwraps your vault key. The fingerprint or the glance does not authorise anything — it produces key material. A forged credential produces different bytes and AES-GCM refuses, which is why the server needs no signature check, no challenge store and no attestation: what it holds (a credential id, a salt, a wrapped key) is inert without the device.

Adding one requires the vault to be open. That is the authorisation: only someone who already has the master password or the recovery code can register a device.
It is an addition, never a replacement. The master password and the recovery code stay, because a passkey is tied to one device and losing the device must not lose the vault. Changing the master password does not affect registered passkeys — they wrap the same vault key.
Remove a device any time in the Security tab; the wrap is deleted and that authenticator stops opening the vault.
Support: Chrome/Edge 116+, Safari 18+ (macOS 15 / iOS 18), and hardware keys with hmac-secret. Where the PRF extension is missing the vault says so and keeps the master password.

Account settings → Security → Two-factor sign-in enrols a time-based one-time code (TOTP) in any authenticator app. From then on every sign-in asks for the six digits. Independently of that prompt, the database itself refuses to hand the vault's rows to a session that has not presented the second factor: the policy on the tables checks the session's assurance level. A cookie stolen from a password-only session sees nothing.

Recovery code, and why there is no "forgot my master password"

If we could reset your master password, we could read your vault — the two are the same capability. So there is no reset. The recovery code, shown once when the vault is created and again whenever you change the master password, is the only way back in. Print it or store it somewhere that is not this account. Both losing the master password and losing the recovery code means the data is unrecoverable, and the setup screen says so before it lets you continue.

What the vault deliberately does not do

No sample data. Every other tracker seeds a demo; a vault of invented passwords would teach the wrong lesson.
No shared vault yet. Sharing a login with a partner needs public-key cryptography between two accounts; it is planned, not shipped.
No AI. The assistant does not read the vault, cannot search it, and is not offered a way to. The vault is excluded from the account snapshot the assistant sees.
No site logos by default. Fetching a logo for "bank.com" tells a logo service that you have an account there. Logos are off unless you switch them on in the Security tab.
No browser extension or autofill. Copy fills the clipboard and clears it after 30 seconds if it still holds what was copied.
No passkey-only vault. A device can unlock it, but the master password and the recovery code remain the way back in when that device is gone.

Import and export

Import reads the CSV a browser or another manager exports — Chrome, Firefox, Bitwarden, 1Password and similar — in your browser, and encrypts each row as it is saved; the file is never uploaded. Export produces CSV or JSON of everything, after the master password is typed again (an unlocked tab is not a mandate to dump the vault), and is free on every plan, because your data is yours.

Free and Pro

The free plan holds up to 25 logins; Pro removes the cap. Encryption, two-factor sign-in, the recovery code, import and export are identical on both — a tier does not buy security.

Where it fits with the password generator

The Password Generator makes the passwords; the vault keeps them. Every password field in the vault carries the generator's strength read and a Generate button, so a new login can be created with a 20-character random password without leaving the sheet. A password older than a year is flagged in the list as a candidate for rotation.

Abrir el gestor de contraseñas →Manual del generador de contraseñas →