Metadata encryption — why URL data is sensitive and most managers ignore it

Every mainstream password manager encrypts your passwords. Most of them store the website addresses those passwords belong to in plaintext on their servers. This design choice — encrypt the credential content, leave the URL readable — was made when the password was considered the only sensitive field. It is a choice that the 2022 LastPass breach made concrete: an attacker obtained not just encrypted vault data but a readable map of every website every affected user has accounts on.

The intuition that website URLs are not sensitive deserves examination. A list of which services someone uses — their bank, their email provider, their employer's systems, their healthcare portal, their cryptocurrency exchange — is genuinely sensitive information independent of the passwords. It enables targeted phishing against those specific services, informs social engineering with known context, and identifies high-value targets for further exploitation.

Only one provider in the mainstream consumer password manager category has made full metadata encryption a core architectural feature. Understanding why it was omitted from the others, and what the tradeoffs of encrypting it are, helps evaluate whether this property matters for your use case.

The assumption that 'the attacker needs my password to do anything with my data' is incomplete. A list of services a person uses is valuable independent of whether credentials are available. Phishing campaigns become significantly more effective when the attacker knows exactly which bank to impersonate for a specific target. This is not theoretical — it is the operational reality of spear phishing and targeted social engineering.

A second assumption is that the provider's zero-knowledge claim covers all sensitive data. Zero-knowledge, as implemented by most managers, is specifically about credential content. It is not a general statement about data minimisation. Providers store and can access URL metadata, login frequency, device information, and account metadata under most implementations. A more accurate description would be 'zero-knowledge for credential content' — not zero-knowledge for the service usage pattern.

A third assumption is that metadata encryption comes with significant usability costs. Encrypting URL metadata does make server-side search and indexing of vault items impossible — the provider's servers see only ciphertext. Proton Pass's implementation handles this through client-side indexing, which performs lookup on the decrypted vault locally rather than querying server-side indices. The usability impact for end users is minimal; the architectural complexity of implementation is non-trivial, which partly explains why other providers haven't adopted it.

Proton Pass encrypts all vault item fields end-to-end: the website URL, the item title, the username, notes, and the password. A compromise of Proton's server infrastructure would produce encrypted blobs with no readable structure — no URL list, no item titles, no usernames in plaintext alongside encrypted passwords. This is architecturally distinct from standard zero-knowledge implementations where encrypted passwords sit alongside readable URL fields.

Every other provider in this comparison stores URL metadata in plaintext on their servers. For Bitwarden, LastPass, Dashlane, Keeper, and NordPass: a server-side compromise or a court order produces readable URL data alongside encrypted credential content. This is not a criticism — it is standard industry practice, and the credential content remains protected. But it is a meaningful architectural difference from Proton Pass's model.

The practical relevance scales with threat model. For most users — people whose risk is primarily credential stuffing and account takeover rather than targeted surveillance — the URL metadata exposure is a secondary concern relative to having strong, unique passwords and adequate 2FA. For journalists, activists, high-value professional targets, or anyone whose service usage pattern is itself sensitive, metadata encryption moves from a secondary to a primary consideration.

Metadata encryption protects against server-side exposure of URL data. It does not protect against client-side exposure: if your device is compromised and the vault is unlocked, all fields including URLs are accessible regardless of server-side encryption. Metadata encryption is a server-trust property, not a device-trust property.

Proton Pass is a newer product with a shorter operational track record than Bitwarden or Dashlane. The metadata encryption architecture is audited and sound; the product has had less time to encounter the edge cases and real-world failure modes that longer-established products have addressed.