Threat Modeling for Password Managers

Introduction

Building a password manager without threat modeling is equivalent to designing a bank vault without knowing who might try to break in.

Threat modeling is the discipline of:

• Identifying what must be protected
• Understanding who may attack it
• Defining how attacks could happen
• Establishing clear security boundaries

This chapter defines the security reality in which password manager must survive.

What Is at Stake (Assets)

Before identifying attackers, we must identify assets.

Primary Assets

• User passwords
• Encryption keys
• Decrypted vault contents

Secondary Assets

• Metadata (domains, usernames)
• Authentication material
• Vault integrity

Among these, encryption keys and decrypted data are the most sensitive.

Exposure of these assets results in total compromise.

Who Are the Adversaries?

A realistic threat model assumes capable, persistent attackers.

External Attackers

• Hackers exploiting software vulnerabilities
• Attackers breaching backend databases
• Automated malware targeting browsers

Internal Threats

• Malicious employees
• Misconfigured access controls
• Insider curiosity or abuse

Infrastructure-Level Threats

• Cloud provider access
• Backup leaks
• Logging and monitoring systems

A secure password manager must assume server compromise is inevitable.

Common Attack Vectors

Database Breaches

Historically, breaches are not hypothetical – they are routine.

If attackers obtain:

• Encrypted vaults
• Authenticated data
• Salts

The system must still protects user secrets

Network Attacks

• Man-in-the-middle attacks
• TLS termination leaks
• Replay attacks

Encryption must assume hostile networks.

Client-Side Attacks

• Malicious extensions
• XSS on visited websites
• Clipboard scaping

These attacks shape how autofill and UI must behave.

Trust Boundaries

A trust boundary separates what must be trusted from what must not.

Trusted

• User-controlled client device (with limitation)
• Cryptographic primitives

Untrusted

• Backend servers
• Networks
• Third-party services

The system must continue to function securely even if untrusted components fail.

Explicit Non-Goals

No system can protect against everything.

This password manager explicitly does not attempt to protect against:

• Fully compromised operating systems
• Hardware keyloggers
• Users voluntarily revealing their master password

Acknowledging non-goals is a sign of mature security design, not weakness.

Threats Introduced by Password Mangers

Ironically, password managers introduce new risks:

• Single point of failure
• High-value attack target
• Expanded attack surface

Without proper architecture, a password manager becomes a catastrophic liability.

Designing for Breach Tolerance

Given the inevitability of breaches, the system must be:

• Breach-resilient
• Damage-limiting
• Zero-knowledge by design

The goal is not preventing breaches, but ensuring breaches reveal nothing useful.

Mapping Threats to Design Decisions

Threat modeling directly informs architecture:

Security decisions must always trace back to a threat.