Threat modelling a credential vault before the beta

Before PulsVault went into beta we sat down and listed who might attack it and how. This is a trimmed version of that exercise, including what it changed.

Method

We used a simple STRIDE-style pass. For each part of the system (client, sync API, storage, account recovery) we asked what an attacker could spoof, tamper with, read or disrupt. Then we ranked by how bad the outcome would be, not by how likely it felt.

Attackers we planned for

Someone who steals our database

The most important case. Because items are encrypted on the device, a database dump yields ciphertext and salts. Offline guessing of master passwords is still possible, so key derivation cost and a minimum password strength check matter.

Someone who reads traffic

TLS everywhere, and the payload is already encrypted before it enters the connection. A broken TLS setup would leak metadata, not contents.

A malicious or curious insider

We cannot read vault contents, but we can see account metadata. We reduced what we log and restricted who can query production data.

Attackers we ruled out

We do not defend against malware on an unlocked device, or against a user who types their master password into a phishing page. We say so in the documentation rather than implying otherwise.

What the exercise changed

1. Recovery became client-side. Our first design had an email-based reset that would have required the server to hold a recovery key. It would have broken the whole model, so recovery codes are generated and kept by the user.
2. Session tokens got shorter lifetimes. A stolen token should not be useful for long.
3. Sync conflicts stopped overwriting. A malicious or buggy client could replace a good item with a bad one. The server now keeps a short version history.

sync:
  keep_versions: 10
  max_item_bytes: 65536
  require_client_version: ">=0.9.0"

What is still open

Shared team vaults are harder: key distribution between members is the part of the design we trust least. We are keeping them in beta until they have been reviewed by someone outside the company.

Why publish this

A threat model that lives in one person's head is not much use. Writing it down gave us a list to test against, and gives users a way to judge whether our priorities match theirs.