Design a password manager like 1Password: system design interview question

How the interviewer opens it

“Design a password manager that stores and synchronizes encrypted vaults across devices. Protect vault contents from the service under a clear threat model. Support secure sharing and account recovery.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Scale
Read and write mix
Offline use and latency
Consistency and availability
Durability and retention
Security boundary
Shared access
Account recovery
Visible metadata
Product boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Store encrypted vaults and provide access from authorized devices.
Synchronize offline edits without silent data loss.
Share a vault with named users and remove their access to future edits.
Recover vault access with a recovery secret that the user keeps.

Usually out of scope

Autofill and browser integration.
Enterprise administration.
Protection after a client compromise.
Guaranteed freshness against a malicious server.
Erasure of copies that former members already hold.

What interviewers ask about

Vault confidentiality: Devices need shared secrets without direct server access to those secrets. Weak passwords still expose encrypted key envelopes to offline guesses.
Edits from several devices: The server cannot inspect encrypted fields. Offline devices can edit or delete the same item without knowledge of other changes.
Access to shared passwords: Removal must coordinate membership and future encryption keys. Offline edits can otherwise expose new content through keys that a former member still knows.
Account recovery: Recovery needs a decryption route that survives device loss. That route must not give the server or an email attacker a universal secret.

Common mistakes

The design promises absolute secrecy despite offline guesses against weak passwords.
The client accepts encrypted vault keys without proof of an authorized sender.
The design separates membership removal from the key epoch change and accepts stale-epoch writes.
The design confuses account login recovery with vault recovery.
The sync path silently replaces concurrent edits.
The design promises complete revocation of data that a recipient already copied.

The bar by level

Senior (L5/E5): Defines the key hierarchy and authenticated envelope context. Implements atomic membership and epoch transitions with stale-write rejection. Handles recovery proofs, sync retries, and deletion conflicts.
Staff (L6+/E6+): Defines identity trust and malicious-server limits. Explains revocation races, old backup exposure, and recovery authorization changes. Plans safe key migration across offline devices without silent data loss.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a password manager like 1Password
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a password manager that stores and synchronizes encrypted vaults across devices. Protect vault contents from the service under a clear threat model. Support secure sharing and account recovery.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

Scope of a strong answer

Core requirements

Store encrypted vaults and provide access from authorized devices.
Synchronize offline edits without silent data loss.
Share a vault with named users and remove their access to future edits.
Recover vault access with a recovery secret that the user keeps.

Usually out of scope

Autofill and browser integration.
Enterprise administration.
Protection after a client compromise.
Guaranteed freshness against a malicious server.
Erasure of copies that former members already hold.

What interviewers ask about

Vault confidentiality

Devices need shared secrets without direct server access to those secrets. Weak passwords still expose encrypted key envelopes to offline guesses.

Edits from several devices

The server cannot inspect encrypted fields. Offline devices can edit or delete the same item without knowledge of other changes.

Access to shared passwords

Removal must coordinate membership and future encryption keys. Offline edits can otherwise expose new content through keys that a former member still knows.

Account recovery

Recovery needs a decryption route that survives device loss. That route must not give the server or an email attacker a universal secret.

Common mistakes

The design promises absolute secrecy despite offline guesses against weak passwords.

The client accepts encrypted vault keys without proof of an authorized sender.

The design separates membership removal from the key epoch change and accepts stale-epoch writes.

The design confuses account login recovery with vault recovery.

The sync path silently replaces concurrent edits.

The design promises complete revocation of data that a recipient already copied.

The bar by level

Senior (L5/E5)

Defines the key hierarchy and authenticated envelope context. Implements atomic membership and epoch transitions with stale-write rejection. Handles recovery proofs, sync retries, and deletion conflicts.

Staff (L6+/E6+)

Defines identity trust and malicious-server limits. Explains revocation races, old backup exposure, and recovery authorization changes. Plans safe key migration across offline devices without silent data loss.