Your vault is created and encrypted on your device. You decide where its encrypted copies go, which integrations to connect, and how to recover access if a device is lost.
The current V3 format separates the randomly generated root key from your unlock credentials. Changing your master password can create a new credential wrap without re-encrypting every record.
Passary generates a random vault root key locally. You choose a master password and can add a keyfile. Argon2id processes the password; HKDF-SHA256 binds its result, the optional keyfile input, and vault identity into a key that wraps the root key.
Keys derived from the root key protect vault records, attachments, and the manifest with AES-256-GCM. Authenticated encryption detects changes to protected ciphertext. V3 also uses device grants and signed revisions to support authorized devices.
The Windows app opens and saves a .passaryvault file at a chosen location. The web app can use a local file or keep an encrypted copy in that browser's IndexedDB. Core vault use needs no Passary account or connection.
You can configure a selected sync folder, WebDAV, S3-compatible storage, or a relay. The selected destination receives an encrypted vault object, not the master password, keyfile, or readable records. Paired browser extensions and consented breach checks are separate optional features.
Older vault formats have different internals. For V3 algorithms and parameters, read the encryption architecture.
Passary does not require a provider-hosted vault database for everyday use. A Windows vault file remains where you save it; a browser-stored vault remains in that browser until you export it, choose a file, or configure another destination. Clearing browser site data can remove that browser's copy.
A configured folder or network destination can hold an encrypted copy. Its operator may observe object identifiers, sizes, timing, and connection metadata, retain older versions, or affect availability. Encryption does not make those details invisible or guarantee the latest copy will be delivered.
A storage destination is not given the credentials or root key needed to read encrypted records. Modified authenticated ciphertext fails verification. Local vault use works offline.
Readable file headers and transport can reveal metadata. Malware, a compromised browser or extension, or malicious app code can access an unlocked vault. A stolen encrypted copy can be attacked offline if your password is weak.
Optional breach checks require consent and send five-character SHA-1 hash prefixes to the Pwned Passwords service, not the complete password or full hash. See the security model and zero-knowledge boundaries for more detail.
There is no Passary account reset or provider backdoor. Make an independent encrypted backup or recovery kit, retain any required keyfile separately and securely, and test that you can reopen a copy. A snapshot on the same device is not a complete disaster-recovery plan. Losing every usable copy or its required credentials can permanently block access.
