Local vault
Your primary vault lives on your device.
SECURITY
Local-first by design.
A clear look at how your vault is protected—from your Master Password to your encrypted backups.
01 · SECURITY PHILOSOPHY
Your device is home to your vault.
Pass & Note does not operate a server-side vault containing your passwords and notes.
No server-side recovery
There is no provider password reset that decrypts your data.
Encrypted backups
You choose where to keep independent encrypted exports.
02 · ENCRYPTION ARCHITECTURE
How your vault is protected.
Your Master Password protects a separate vault key. That vault key unlocks the encrypted database.
01 Protect the vault key
- Master Password Processed locally; not saved by the app
- PBKDF2-HMAC-SHA256 600,000 iterations · unique 32-byte salt
- 256-bit key-encryption key AES-256-GCM wraps the random vault key
- Encrypted vault-key envelope iOS Keychain / Android Keystore-backed storage
02 Protect the database
- Random 256-bit vault key Generated when a new vault is created
- SQLCipher key derivation PBKDF2-HMAC-SHA512 · 256,000 iterations
- Database key material AES-256-CBC + HMAC-SHA512
- Encrypted local vault Your passwords and secure notes
Layer 1: protecting the vault key
PBKDF2 processes your Master Password with a unique salt to derive a 256-bit key-encryption key. AES-GCM uses that key to encrypt and authenticate the vault key. This encrypted package is called a key envelope.
Layer 2: protecting the database
The unlocked vault key is supplied as SQLCipher’s passphrase input. SQLCipher derives its own key material, encrypts database pages, and checks their authentication codes when reading them.
Your Master Password does not directly become the database encryption key.
03 · MASTER PASSWORD
Your Master Password is never stored.
The app processes your Master Password locally using PBKDF2-HMAC-SHA256 with 600,000 iterations and a unique 32-byte salt.
The resulting 256-bit key-encryption key protects your vault key using AES-256-GCM. Your Master Password and database encryption key have different roles.
Changing your Master Password
- Unlock the existing key Your current Master Password opens the stored key envelope.
- Derive a new wrapping key Your new Master Password and a fresh salt produce a new key-encryption key.
- Protect the same vault key again The app saves a new AES-GCM envelope. The database continues using its existing vault key.
A password change does not update previously exported files or revoke copies of an old key envelope. Keep your older backups and passwords safe.
04 · RANDOM VAULT KEY
A separate key for your encrypted vault.
Each newly created vault receives its own cryptographically secure, random 256-bit vault key.
- Master Password
- Protects the vault key
- Vault key protects the database
Changing your Master Password re-wraps the existing vault key rather than re-encrypting the database. Previously exported files still require the password used when they were created.
Older iOS vaults may retain their existing derived key when migrated to the current envelope format.
05 · SQLCIPHER
Encrypted storage, page by page.
SQLCipher protects the mobile database using AES-256-CBC and HMAC-SHA512 authentication.
The unlocked vault key is supplied to SQLCipher as passphrase input. SQLCipher applies its own key derivation before encrypting database pages.
Technical details
| SQLCipher | iOS 4.10.0 · Android 4.17.0 |
|---|---|
| Cipher | AES-256-CBC |
| KDF | PBKDF2-HMAC-SHA512 |
| KDF iterations | 256,000 (default) |
| HMAC | HMAC-SHA512 |
| Page size | 4,096 bytes (default) |
| Salt | 16 bytes (default) |
06 · KEYCHAIN / SECURE STORAGE
Platform security, shared principles.
Both apps protect key storage using the security services available on their platform.
iOS
Keychain protection
The password-protected key envelope is stored in the Keychain with
kSecAttrAccessibleWhenUnlockedThisDeviceOnly
.
When biometric unlock is enabled, a separate vault-key item uses
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
and
.biometryCurrentSet
. Removing the device passcode or changing enrolled biometrics invalidates that biometric access; the Master Password is needed again.
CryptoKit handles AES-GCM. CommonCrypto handles password derivation and provides the Apple SQLCipher cryptography implementation.
ANDROID
Keystore-backed protection
The password-protected envelope is additionally encrypted using an AES-GCM key in Android Keystore before being saved in app-private storage.
Biometric quick unlock uses a separate Keystore wrapping key requiring strong biometric authentication for each use. The key is configured to become invalid when biometric enrollment changes.
The app uses
FLAG_SECURE
to restrict screenshots and non-secure displays, and sets
allowBackup="false"
to disable Android’s standard app backup. Device behavior can vary; create explicit encrypted exports for recovery.
07 · BIOMETRIC UNLOCK
Quick access to the same protected vault.
Supported device biometrics authorize access to the vault key. Your fingerprint or face is not the database encryption key.
Biometric access is configured to become invalid when enrollment changes. Use your Master Password to unlock and set up quick unlock again. Keep that password available for exports and whenever biometric access is unavailable.
Biometric setup and troubleshooting →08 · LOCK & PRIVACY
Reduce exposure when you step away.
Explicit vault locking
Locking closes the database session and returns the app to its locked screen. Authentication is required to open the vault again.
Background privacy
A privacy shield covers sensitive views when the app becomes inactive. Returning from the background requires authentication once your selected auto-lock interval has elapsed. Hiding the screen and closing the database are distinct controls.
Editor autosave
Note editors save changes around app lifecycle transitions. On iOS, the app asks sensitive editors to autosave before displaying the privacy shield.
Clipboard controls
Mobile settings let you choose when copied passwords expire or clear on backgrounding. iOS also marks copied passwords as local-only. Expiration reduces the time a value is available; it cannot undo a copy already captured by another app.
09 · ENCRYPTED BACKUPS
A separate encrypted container, under your control.
Exports contain selected records or a full collection of passwords and notes. They are independently encrypted before being handed to your chosen storage location.
- Confirm your Master Password The mobile app verifies access to the vault.
- Generate a fresh export salt A new 32-byte salt is used for each export.
- Derive the export key PBKDF2-HMAC-SHA256 · 600,000 iterations · 256-bit key.
- Encrypt with AES-GCM The record payload receives authenticated encryption.
- Choose where to save Save a .pnpass, .pnnote, or .pnvault file using your device’s file picker.
Pass & Note does not need your backup uploaded to a server to decrypt it. The Recovery Viewer opens it locally in your browser.
The encrypted payload protects record contents. Container metadata—including format, creation date, content type, and item count—is readable. Older backups require the Master Password used when they were created, even after a password change.
See the mobile export guide →10 · THREAT MODEL
What these protections can—and cannot—do.
Encryption protects data at rest. Its effectiveness also depends on a strong Master Password, device security, and how you handle unlocked data.
Designed to reduce these risks
- Reading a stolen encrypted vault: the database needs its key to open.
- Reading a stolen encrypted backup: records require the export password; password guessing remains possible.
- Undetected changes to encrypted data: authentication checks detect changes to protected database pages and export payloads.
- Exposure through a provider vault database: Pass & Note does not operate a server-side vault store.
- Interception during recovery upload: the viewer needs no backup upload or remote decryption request.
Outside the protection boundary
- Malware, keyloggers, or a compromised operating system.
- Someone who knows your Master Password or has obtained the vault key.
- Someone with access to an unlocked vault or recovery session.
- Malicious browser extensions or a tampered website.
- Screenshots, external cameras, or clipboard monitoring.
- Lost files, forgotten passwords, or destroyed devices without a usable backup.
ARCHITECTURE, NOT A SECURITY RANKING
Cloud-synced and local-first vaults.
Different storage models make different tradeoffs. Many cloud-synced products also encrypt locally and never send the Master Password to their provider.
| Design choice | Cloud-synced vaults | Pass & Note |
|---|---|---|
| Primary storage model | Local and provider-hosted encrypted copies, depending on product | Local encrypted database on the user’s device |
| Provider account | Often required for sync | No vault account required |
| Provider stores the vault | Typically stores an encrypted copy | No Pass & Note server-side vault copy |
| Master Password handling | Many derive keys locally; implementation varies | Processed locally; not sent to a vault service |
| Local database protection | Varies by product | SQLCipher · AES-256-CBC + HMAC-SHA512 |
| Separate vault key | Available in many designs | Random key protected by a password-derived wrapping key |
| Backup and sync | Often automatic sync; offline export varies | User-managed encrypted exports |
| Browser recovery | Varies by product | Read-only, local processing of a compatible backup |
| Forgotten Master Password | Recovery options vary; account reset may not recover data | No server-side password reset or decryption recovery |
This comparison describes architectural differences, not a security ranking. Security depends on implementation, threat model, device security, and how each product is used.
What Pass & Note does not need to know
Your Master Password is processed on your device. Pass & Note does not maintain a server-side copy of your vault or require an encrypted backup upload for recovery.
You decide where exported backups are stored. If you choose a cloud storage provider, that provider’s handling of the saved file is separate from Pass & Note’s local processing.
11 · TECHNICAL SPECIFICATIONS
The details behind the design.
Architecture v1.0 · September 2026. Dependency versions below describe the documented mobile implementations; installed app versions may differ.
| Specification | Implementation |
|---|---|
| SQLCipher dependency | iOS: 4.10.0 · Android: 4.17.0 |
| Database cipher | AES-256-CBC |
| Database page authentication | HMAC-SHA512 |
| SQLCipher KDF | PBKDF2-HMAC-SHA512 · 256,000 iterations (default) |
| SQLCipher page size / salt | 4,096-byte pages · 16-byte salt (defaults) |
| Master Password KDF | PBKDF2-HMAC-SHA256 · 600,000 iterations |
| Master Password salt / derived key | 32-byte random salt · 256-bit key-encryption key |
| New vault key | 256-bit cryptographically secure random key |
| Vault-key wrapping | AES-256-GCM |
| Export encryption / format | AES-256-GCM · PASSNOTE container v1 |
| Export KDF / salt | PBKDF2-HMAC-SHA256 · 600,000 iterations · fresh 32-byte salt |
| Export sealed payload | 12-byte nonce + ciphertext + 16-byte authentication tag |
| Apple crypto APIs | CryptoKit (AES-GCM); CommonCrypto (PBKDF2 and SQLCipher provider) |
| Database integration | iOS: GRDB.swift 6.24.1 + SQLCipher · Android: SQLCipher Android API |
| Browser recovery | Web Crypto API · in-memory decryption · read-only records |
SQLCipher’s database defaults and page authentication are described in Zetetic’s security design and SQLCipher’s API reference .