Can a Password Manager Provider Read Your Passwords?

The word encrypted is not enough. A provider can encrypt data while still holding a copy of the key. If the provider can reset that key, silently derive it, or ask its server to decrypt your vault, then the provider may still be technically capable of reading your data.

The three questions that determine the answer

Ask any password manager:

1. Where is the vault encrypted and decrypted? It should happen on your device.
2. Who can obtain the decryption key? A zero-knowledge provider should not receive it.
3. What happens during recovery? A recovery system that restores the vault must have a legitimate cryptographic path to a decryption key. That path is part of the security model.

If the company cannot answer those questions precisely, “military-grade encryption” is empty advertising.

How Lockstep separates authentication from encryption

Lockstep uses separate derivation paths for signing in and unlocking the vault.

Your master password and two independent, per-user salts are processed on your device. New accounts use Argon2id with 64 MiB of memory, three passes, and one lane. Older PBKDF2-SHA-256 accounts are supported and can be upgraded after a successful login.

The client derives:

• An authentication key, which is sent to the server and then protected again with bcrypt for login verification.
• An encryption key, which remains on the device and is used to unwrap a randomly generated vault key.

The vault key encrypts each saved field with AES-256-GCM. The server stores encrypted fields, their initialization vectors, authentication tags, and the wrapped vault key. It does not receive the master password, the encryption key, or an unwrapped vault key.

This separation matters. A server must be able to verify that you may sign in without also gaining the material needed to decrypt your vault.

Argon2id is a memory-hard password-derivation function intended to make offline guessing more expensive. The OWASP Password Storage Cheat Sheet recommends Argon2id and lists several acceptable parameter combinations. Lockstep's 64 MiB, three-pass configuration exceeds OWASP's listed minimum memory configuration.

AES-GCM provides both confidentiality and integrity: it encrypts the content and detects unauthorized modification when used correctly. GCM is standardized in NIST Special Publication 800-38D, and OWASP recommends authenticated modes such as GCM in its Cryptographic Storage Cheat Sheet.

What Lockstep's server can still see

Zero knowledge does not mean zero data.

The service necessarily handles operational information such as:

• Your account email address
• Authentication and session records
• Subscription status
• Device records
• Timestamps and security events
• The number and size of encrypted records
• Network metadata made visible by normal web requests

The server also receives the client-derived authentication key during login. That value is not your master password and is not the vault-decryption key, but it is still sensitive authentication material and is protected server-side.

A precise privacy statement should distinguish encrypted vault contents from account metadata. Claiming that a provider “knows nothing about you” would be false.

What happens if the database is stolen?

A database compromise could expose:

• Encrypted vault records
• Wrapped vault keys
• Publicly stored salts
• Password-derivation parameters
• Hashed authentication verifiers
• Account metadata

Salts and work-factor settings are not supposed to be secret. Their job is to prevent precomputed attacks and make each account expensive to guess independently.

An attacker could still perform offline guesses against stolen verification material. A long, unique master password remains critical. Memory-hard derivation raises the cost of each guess; it does not make a weak password strong.

For practical advice, see Is It Safe to Put Everything in One Password Manager? and What Happens If You Forget Your Master Password?.

Where zero knowledge stops

Client-side encryption protects data at rest on the server. It does not solve every threat.

If malware controls an unlocked device, a malicious browser extension can read the page, or a user enters a master password into a convincing phishing site, encryption cannot undo that compromise. Plaintext must exist briefly on an authorized device so the user can read and use it.

Other important controls therefore include:

• Multifactor authentication for the password-manager account
• HTTPS-only autofill
• Strict domain matching
• Short-lived sessions
• Device revocation
• Automatic vault locking
• Prompt security updates
• A clean and trustworthy endpoint

NIST requires covered verifiers to allow password managers and autofill and notes that password managers help users choose stronger passwords. It also emphasizes phishing-resistant authentication at higher assurance levels in SP 800-63B.

How to evaluate another provider

Look for documentation that answers all of the following:

• Is vault encryption performed locally?
• Is the vault key ever sent to the provider unwrapped?
• Are encryption and authentication keys independent?
• Which password-derivation function and parameters are used?
• Is authenticated encryption used?
• Are initialization values unique?
• What metadata remains visible?
• Can support reset the master password and restore vault contents?
• How do recovery and emergency access obtain decryption capability?
• Can users export data in a usable form?
• Has the design received independent security review?

The last item matters. This guide documents Lockstep's implemented architecture as reviewed on August 27, 2026; it is not a claim that the product or any software is impossible to compromise.

The bottom line

A password manager provider can avoid being able to read your vault, but only if the cryptographic design removes that ability. Lockstep encrypts vault contents on the client and keeps the unwrapped vault key and encryption key away from the server. The server still processes account metadata and authentication material, and your endpoint remains part of the trust boundary.

That is a narrower claim than “we know nothing.” It is also a claim the architecture can actually support.