AzAd Vault is built so that AzAd Solutions never receives your master password or decrypted vault contents. When you enable Google Drive sync, only encrypted blobs land in your personal Drive app folder — we cannot read them even with server access. For documents and photos, our sister product FileFolders.com is a separate product: Vault is for secrets, FileFolders is for files.
Zero-knowledge means the party that hosts sync or account identity is not also holding the keys to your secrets. Your AzAd account can link devices and Premium entitlement; your master password stays local and is never uploaded. That separation is the foundation of the threat model below.
A guided checklist walks you through biometrics, backups, imports, and vault hardening — so you always know where you stand. Security audit is included on the free tier.
Honest security pages draw a clear boundary. AzAd Vault is designed to keep vault secrets confidential even if cloud sync storage, network observers, or AzAd’s own account infrastructure are compromised — because those systems only ever see ciphertext.
Someone with access to your Google Drive app folder, a stolen .azvault backup file, or a database dump of encrypted local storage should not be able to read passwords, cards, notes, or TOTP secrets without your master password. Network traffic for sync carries only encrypted payloads. Account sign-in for identity and Premium does not grant AzAd Solutions (or an attacker who phishes our account layer) the ability to decrypt your vault.
If an attacker already controls your unlocked device — for example malware that reads the screen after you unlock, a compromised OS that intercepts biometrics while the vault is open, or someone watching you type the master password — no password manager can fully protect you. Physical access to an unlocked session, coerced disclosure of the master password, and device-level keyloggers sit outside the crypto boundary. We harden daily use with auto-lock, clipboard timeouts, and biometric gates, but the master password remains the root of trust.
That is why we recommend a strong, unique master password, enabling biometrics or PIN for day-to-day unlock, keeping backups, and reviewing the in-app security audit. More product detail lives on the features page; install paths are on download.
Only encrypted data transits to Google Drive (when sync is enabled). Your master password and derived keys never leave local secure storage. Plaintext vault fields are not sent to AzAd Solutions analytics, crash logs, or support tooling.
Your master password derives keys on-device via Argon2id. A session key is stored in secure hardware or OS storage (Android Keystore / Windows DPAPI) so you are not typing the master password for every action.
Each password, card number, note, and attachment is encrypted with AES-256-GCM before it is written to the local database or included in an export. What you see after unlock is decrypted in memory only while the vault is open.
Google Drive receives encrypted vault blobs in your personal app folder. AzAd Solutions has no decryption keys. Optional scheduled backups and backup history also store ciphertext you control.
HMAC-SHA256 on backups detects tampering or corruption. Restore fails fast if the password or file is wrong — you are not left with silently damaged data.
Plaintext is the readable secret — “MyP@ssw0rd!” or a full card number. Ciphertext is the scrambled output of encryption: a blob of bytes that looks like noise without the right key. AzAd Vault’s job is to keep plaintext on your unlocked device only, and to ensure that anything that leaves the device (Drive sync, .azvault files, attachment blobs) is ciphertext. If someone copies a backup off USB or from Drive, they still face Argon2id + AES-256-GCM before anything becomes readable.
A KDF (key derivation function) turns your master password into cryptographic keys. “Memory-hard” means the algorithm is deliberately expensive in RAM, not just CPU cycles. That slows down attackers who try billions of password guesses on GPUs or custom hardware — each guess must allocate a large memory buffer, which is costly at scale.
AzAd Vault uses Argon2id with approximately 64 MB of memory, 3 iterations, and parallelism 4. In practice: unlocking is still comfortable on a phone or PC, but offline cracking of a stolen encrypted vault is far harder than with older password hashes that were cheap to parallelize. Argon2id mixes the strengths of Argon2i and Argon2d variants and is widely recommended for password hashing and key derivation.
AES-256-GCM is authenticated encryption: it encrypts your data and also produces a tag that detects modification. The “256” means a 256-bit key. GCM (Galois/Counter Mode) is a standard mode used across modern apps and browsers.
A nonce (number used once) is a unique value paired with each encryption operation so that encrypting the same password twice does not produce identical ciphertext patterns an attacker could exploit. AzAd Vault uses unique nonces per field encryption. Reusing a nonce with the same key would be dangerous; the design avoids that class of mistake by generating fresh nonces for each sealed field.
An HMAC is a keyed integrity check. When you create an encrypted .azvault backup, HMAC-SHA256 lets the app verify that the file was not truncated, corrupted, or quietly altered before restore. If the master password is wrong or the file is damaged, unlock fails immediately instead of loading garbage. That pairs confidentiality (AES-GCM) with integrity (HMAC) for portable backups you might copy to USB, NAS, or another cloud.
On Windows, session material is protected with DPAPI (Data Protection API) — OS-level encryption tied to your Windows user profile. On Android, Keystore-backed storage protects session keys similarly. These mechanisms reduce the chance that a casually copied app folder yields an unlocked vault; they do not replace the master password for restoring encrypted backups on a new device.
Browsers are convenient for saving logins, but they optimize for sync and UX inside one vendor ecosystem. A dedicated zero-knowledge password manager is built so that sync providers and product vendors are not trusted with plaintext secrets.
Browser password stores are often decryptable when you are signed into the browser profile. AzAd Vault requires the vault master password (or an unlocked local session) before secrets are available — and Drive sync never holds the keys.
Beyond logins, AzAd Vault stores cards, IDs, secure notes, TOTP codes, and encrypted attachments in one model — with a security audit that flags weak and reused passwords.
Android, Windows, and Chrome share the same .azvault crypto stack. You are not locked to a single browser’s sync format when you move between phone, desktop, and web autofill.
Import from browser CSV and other managers when you migrate; export encrypted backups you control. See FAQ for supported formats.
None of this means “never use a browser.” It means treating browser-saved passwords as convenience storage, and using AzAd Vault when you want a clearer zero-knowledge boundary, authenticator codes, attachments, and family Premium seats managed separately from Google or Microsoft account recovery.
PIN or biometrics for daily unlock; biometrics never replace the master password for backup restore on a new device.
Vault locks after inactivity. Re-authentication is required before secrets are visible again.
Copied passwords clear from the clipboard automatically after a short interval.
Detects weak, reused, and expiring passwords. Tracks checklist completion so hardening is guided, not guesswork.
Vault contents are never logged or transmitted in plaintext. See our Privacy Policy for details.
Shared vault_core across platforms — one encryption implementation for Android, Windows, and Chrome.
On Windows, your encrypted vault lives at %USERPROFILE%\Documents\AzAd Vault\azad_vault.db. Session keys use Windows DPAPI. Desktop Google sign-in uses OAuth via azadvault.com/oauth/desktop — your Google password is never sent to AzAd Solutions.
By design, your master password cannot be recovered. If you have an encrypted .azvault backup and remember the password used to create it, you can restore. Otherwise a new vault must be created. This is the trade-off of true zero-knowledge security — and why backup history and scheduled backups (included on Free) matter.