What zero-knowledge means here
In Passary's storage design, a provider holding an encrypted vault copy is not given the master password, optional keyfile, or vault root key needed to read its records. You can also use the core vault without an account or provider-hosted copy.
A confidentiality boundary, not an absolute guarantee
Encryption does not protect an unlocked vault from malware, a compromised browser or extension, or malicious code delivered as an app update or web page. It also cannot force a storage provider to retain or serve your latest copy.
How a V3 vault is protected
A random root key
A new vault gets a randomly generated root key. Vault records, attachments, and manifests are encrypted locally with keys derived from it.
Your unlock credentials
Argon2id processes the master password. HKDF-SHA256 combines its result with an optional keyfile input to derive a key that unwraps the root key on your device.
Authenticated encryption
AES-256-GCM protects encrypted vault content and detects modification. V3 device grants and revision signatures use P-256 keys to support authorized devices.
The master password is not a server login. A strong, unique password - and a protected keyfile if you use one - still matters because a stolen encrypted vault can be attacked offline. See the encryption details for format and parameter information.
Where copies can live
Local-first does not mean a vault can never leave your device. The destination depends on the features you choose.
On your device
Windows saves an encrypted .passaryvault file where you choose. The web app can work with a local file or browser storage. Local vault listings and file headers also contain non-secret metadata.
In an optional sync destination
If you configure a selected folder, WebDAV, S3-compatible storage, or a relay, an encrypted vault copy is transferred there. The destination can observe object identifiers, size, timing, and connection details, and can affect availability.
In your backups
Snapshots, exports, and recovery kits contain encrypted vault material. A local snapshot is not automatically an independent backup; keep and test a separate copy.
Sync can run after you configure an adapter. Its destination receives an encrypted vault object, not plaintext records. HTTPS and endpoint credentials still matter, and a provider may log access metadata or retain old copies.
What remains visible or trusted
Protected from a storage operator
A sync provider is not supplied with readable vault records, your master password, or your keyfile. A copied encrypted vault still requires a valid unlock path.
Not concealed by encryption
Vault headers and transport can expose identifiers, format information, timestamps, sizes, endpoints, and activity patterns. A sync provider can also deny service or return an older copy.
Your device and software
You must trust the operating system, cryptographic implementation, installed Windows app or served web code, and paired browser extensions while they interact with an unlocked vault.
Optional local unlock
On Windows, an explicitly enrolled device grant can use Windows Hello or a device PIN with current-user DPAPI. This convenience path does not replace protecting the device or keeping your master-password recovery path.
Network use is a choice
Creating, unlocking, editing, and saving a local vault do not require a Passary account or connection. Configured sync uses its selected destination. Paired browser extensions exchange data with an unlocked vault, and a one-time compromised-password check requires consent before it sends five-character SHA-1 hash prefixes to the Pwned Passwords service. Neither the full password nor its full hash is sent by that check.
Recovery is your responsibility
There is no Passary account password reset or provider backdoor. An encrypted recovery kit or backup can restore a copy of the vault, but it does not remove the need for the credentials required to unlock that copy. Losing every usable vault copy - or its required password or keyfile - can mean permanent loss of access. Keep an independent backup and test it before you need it.
How to check the model
- Create and save a local vault while disconnected, then reopen it with its required credentials.
- Inspect an exported
.passaryvaultfile: encrypted records coexist with readable headers and metadata. - Use browser network tools to distinguish ordinary app loading from optional sync and consented breach-check requests.
- Test restoration from a separate encrypted backup or recovery kit; do not treat an untested local snapshot as disaster recovery.
These checks illustrate design boundaries; they are not proof that a particular build or device is uncompromised. Read the broader security model and encryption architecture for further detail.