Encrypted Backup (.avbk format)
3-minute read · v1.2 · Free, Pro, & Collector+
AssetVault is offline-first, so keeping a usable backup matters when a device breaks, is lost, or is replaced. Encrypted Backup wraps supported inventory metadata and local file references in a password-protected file. It does not contain the referenced photo or document binaries. The password is not persisted by AssetVault, and AssetVault has no master key.
How it's encrypted
Each .avbk file is an envelope built from three primitives:
- AES-256-CBC — AES with a 256-bit key in cipher-block-chaining mode. Industry-standard symmetric encryption.
- PBKDF2-SHA256, 100,000 iterations — turns your password into the encryption key. The 100K iterations slow down brute-force attacks by 5+ orders of magnitude.
- HMAC-SHA256 — authenticates the ciphertext so a tampered backup file fails to decrypt instead of producing garbage.
The encrypt-then-MAC envelope means even one byte changed in the file causes restore to fail cleanly. No partial decryption, no silent corruption.
Why we chose this design
Encrypted Backup lets you protect metadata before saving the file to storage you control:
- You set the password. The backup flow handles it locally and does not transmit or persist it; no password hash is stored for recovery.
- No master key. There's no AssetVault-side recovery flow. If iCloud / Dropbox / your phone all fail at once, we can't help. Save the password the way you save your most important records.
- The password is held in component state during the modal flow only, then discarded when the modal unmounts. It's not persisted to SecureStore, not written to logs.
Make a backup
- Open Settings → Encrypted Backup (recommended for cloud).
- Type a password. Make it long (15+ chars), unique to this backup, and write it down somewhere offline.
- Confirm the password. AssetVault generates the .avbk file and hands it to your share sheet.
- Pick where to save: Files (local), iCloud Drive, Google Drive, Dropbox, email to yourself, AirDrop to a Mac, etc.
- The success toast confirms the item count and encrypted-file size. That verifies a file was created, but you should also keep the password and periodically test a restore before depending on any backup.
Restore from a backup
- Install AssetVault on the new device.
- Settings → Restore. Pick the .avbk file from your share sheet.
- AssetVault detects the encrypted format and prompts for the password.
- Type the password. Wrong password? AssetVault refuses to decrypt and re-prompts — the file picker stays cached so you don't pick it again.
- Right password? The supported metadata restores. Media is available only if the referenced files still exist at usable paths.
Encrypted vs cleartext backup
Settings has two backup options:
- Backup (JSON) — cleartext metadata export. Smaller and directly restoreable, but anyone who obtains the file may be able to read its contents.
- Encrypted Backup (.avbk) — password-protected. Recommended for any cloud storage, email, or sharing across devices.
If you're moving to a new phone or storing metadata in the cloud, prefer the .avbk path and use a strong, unique password. Create a separate Full Export ZIP if you also need a portability archive of media.
What's in a backup
A .avbk file contains supported inventory metadata such as items, values, conditions, reminders, loans, maintenance logs, condition-timeline entries, flag-check history, and wishlist entries. It does not contain image binaries — only local file references. Settings → Full Export creates an unencrypted ZIP containing CSV, JSON, and media files the app can read. AssetVault can inspect and restore that ZIP directly, reattach verified archived media, and report unavailable media.
Threat model
Encrypted Backup defends against:
- Cloud storage breach (iCloud / Dropbox / Drive). The attacker gets ciphertext + a 100K-iteration PBKDF2 derivation in the way of every guess.
- Lost phone with the .avbk file in iCloud. New phone restores from the backup with your password.
- Accidental email forward. A strong, unique password makes the contents harder for the recipient to recover.
It does not defend against:
- A password you wrote in plaintext next to the backup file.
- An attacker guessing a weak or reused password. Longer, unique passwords provide stronger resistance; no password should be described as uncrackable.
- Loss of the password. There's no backdoor.