Security Principles
The core vault works without an account or network connection. Optional integrations add specific trust and metadata exposures, but do not give a sync provider the vault decryption key.
Client-side cryptography
Vault encryption, decryption, and password-based key derivation run in the app on your device.
User-controlled access
A master password and optional keyfile unlock the vault; enrolled device grants are another explicit local access path.
Data minimization
Vault contents are encrypted at rest. File headers, local listing metadata, and sync transport metadata are not all secret.
These properties depend on the integrity of the app, your device, and the credentials and backups you maintain.
System Architecture Overview
Local Vault Storage
Windows stores encrypted .passaryvault files where you choose. The web app can use a local vault file or browser storage. Encrypted snapshots and recovery material may also be kept locally.
File headers and local records can expose non-secret details such as format, identifiers, and timestamps. Decrypted records exist in memory while the vault is unlocked.
On-Device Cryptography
The Windows app uses the shared Rust vault core; the web app uses browser-side cryptography. Both implement the V3 encrypted vault format.
Master passwords, keyfiles, and decrypted vault contents are not sent to sync destinations. Optional features may make other network requests, described below.
Optional Encrypted Sync
You can configure a selected folder, WebDAV, S3-compatible storage, or a relay. Sync transfers an encrypted vault object; configured network destinations are not given your master password or vault root key.
A destination can still observe connection details, object identifiers, sizes, and timing, and can withhold or delete data. Keep an independent, verified backup.
Offline by Default
Create, open, edit, and save a local vault without a Passary account or telemetry. Sync and browser-extension pairing are optional.
A configured sync adapter can make network requests. In the Windows or web app, an explicitly requested breach check sends five-character SHA-1 hash prefixes to the Pwned Passwords range API, not complete passwords.
Cryptographic Implementation Summary
Current V3 vaults combine a randomly generated root key with password-based key wrapping, authenticated encryption, and signed device revisions. The table summarizes the principal primitives, not an independent security certification.
| Purpose | Algorithm |
|---|---|
| Password-based key derivation | Argon2id |
| Password and optional keyfile binding | HKDF-SHA256 |
| Symmetric encryption | AES-256-GCM |
| Device grants and revision signatures | ECDH / ECDSA P-256 |
| Randomness | Browser or operating-system CSPRNG |
Specific parameters, data flows, and implementation details are documented in the Encryption Architecture specification.
Threat Model & Protection
This section summarizes the threat scenarios addressed by Passary’s design, as well as conditions that are explicitly out of scope.
Threats Addressed
Server Compromise
A compromise of a configured sync destination should expose encrypted vault objects and observable transport metadata, not the master password or vault root key. An attacker can still delete, withhold, or attempt to replace data.
Network Interception
Sync transfers encrypted vault objects. Transport security still matters for credentials, capabilities, metadata, and preventing interception or service impersonation.
Offline Attacks
Argon2id raises the cost of guessing a stolen vault’s master password; AES-GCM detects modification. A weak password can still be guessed offline, especially without a keyfile.
Mass Collection
Core use needs no provider-hosted vault database. If you enable sync, your chosen destination holds an encrypted copy and may retain its own logs or backups.
Out-of-Scope Threats
Compromised Client Devices
Passary cannot protect against malware, keyloggers, or malicious browser extensions operating on an unlocked device.
Coercion
The system does not provide plausible deniability or mechanisms to resist forced disclosure.
Weak Credentials
Cryptography increases attack cost but cannot compensate for weak or reused passwords.
Loss, Rollback, and Availability
Encryption cannot restore a deleted vault, recover a lost password or required keyfile, or guarantee that a sync provider serves the latest copy. Keep and test independent backups.
Optional Protection Layers
Keyfiles and device unlock
A keyfile can be required alongside the master password. On Windows, an explicitly enrolled device grant can be gated by Windows Hello or a device PIN and protected with current-user DPAPI. This is a convenience layer, not a defense against malicious code running as your Windows user; password and keyfile unlock remain available.
Encrypted copies and recovery
The apps support encrypted snapshots and explicit export or backup workflows. A local snapshot is not automatically an off-device backup. Verify a separate recovery copy before relying on it, particularly before changing credentials or migrating an older vault.
Browser integration
Paired extensions can request autofill data from an unlocked web or Windows vault. Pair only browsers you trust, review access, and lock the vault when it is not in use. A compromised browser or extension can expose data presented during a session.
Optional breach lookup
In the Windows or web app, a one-time compromised-password check requires consent. Passwords are hashed locally; only short hash prefixes are sent to an external range API. The service can see those prefixes and connection metadata, but not full passwords or full hashes.
User Responsibilities
Security guarantees depend on several user-controlled factors:
- •Maintaining device security (OS updates, disk encryption)
- •Choosing a strong, unique master password
- •Protecting optional keyfiles if used
- •Avoiding untrusted apps and browser extensions
- •Keeping and testing an independent encrypted backup
- •Reviewing optional sync destinations and paired browsers
Loss of credentials or keyfiles may result in permanent data loss.
Attack Resistance (Conceptual)
Password Guessing Resistance
Password-based attacks are mitigated through memory-hard key derivation, limiting the effectiveness of GPU and ASIC-based cracking.
Side-Channel Considerations
Passary uses browser and operating-system cryptographic primitives, but does not claim protection against all timing, memory, or compromised-runtime attacks.
Future Cryptanalysis
No claims are made regarding resistance to hypothetical future cryptographic breakthroughs beyond current best practices.
Trust Model
Encryption reduces what storage and network operators can read. It does not remove every trust requirement, especially for software delivery, availability, and devices you use to unlock.
Not Trusted with Vault Plaintext
- An optional encrypted-sync storage provider
- Network observers of encrypted vault transfers
- The operator of an opaque relay holding your encrypted copy
Trust Still Required
- Your device, operating system, and browser or Windows user account
- The cryptographic implementation and installed app or served web code
- Paired extensions while they interact with an unlocked vault
- A sync provider for availability and delivery of the latest copy
Encrypted storage protects confidentiality; it does not guarantee availability or prevent a malicious update to the code you run.
Verification & Transparency
You can inspect the current build and test important boundaries yourself:
Create, unlock, edit, and save a local vault while offline
Inspect an exported vault file and test a restored encrypted backup
Observe which requests appear only after enabling sync or a breach check
Published design details and source code support review, but are not a substitute for an independent audit or your own backup tests.