Muzoovy Vault — Private Password-Manager Architecture

Problem

A useful password manager must protect secrets at rest without making daily capture, update, and autofill workflows brittle. The project explores that balance across browsers, Linux desktop sessions, and Android.

Threat Model

The design treats the server and stored database as unable to interpret vault contents, limits backend reachability to a WireGuard private network, and requires registered device identity. It does not claim protection from a compromised unlocked client, malicious accessibility services, or endpoint capture.

Security boundary: encrypted content, authenticated devices, private network—not an audited or formally certified system.

Architecture

Cryptographic work stays on the client. The backend receives authenticated requests and opaque ciphertext rather than plaintext credentials.

ANDROID / FIREFOX↓CLIENT-SIDE CRYPTO↓TRUSTED DEVICE AUTH↓WIREGUARD PRIVATE NETWORK↓VAULT API↓OPAQUE CIPHERTEXT STORAGE

Client-Side Encryption

Vault items use AES-256-GCM authenticated encryption. HKDF-SHA256 derives a distinct per-item key, reducing key reuse across records while GCM authenticates ciphertext and associated context. Plaintext processing remains client-side.

Device Trust

DESKTOP / Ed25519

The desktop client uses an Ed25519 device identity and Linux Secret Service integration for local secret handling.

ANDROID / P-256

Android uses a P-256 device identity, with local key wrapping protected by Android Keystore.

Android Architecture

Biometric gating controls vault access on Android. A successful unlock creates a one-hour in-memory session. Native AutofillService integration matches exact website hostnames or Android package names, and an encrypted local pending-save queue preserves capture operations until synchronization is available.

Firefox Architecture

Firefox communicates with the desktop client through Native Messaging. The browser side detects credential forms and requests scoped matches; sensitive cryptographic and device operations remain in the native client boundary.

Autofill + Save/Update Flow

New credentials produce a save prompt; a changed password for an exact existing match produces an update prompt. User confirmation precedes client encryption and synchronization.

Network Boundary

The Vault API is gated behind a WireGuard private network. This reduces public network exposure but is one layer, not a substitute for device authentication, encrypted payloads, or endpoint security.

Recovery & Migration

Recovery is designed around an offline recovery envelope and encrypted backups. Bitwarden migration tooling verifies imported data before any replacement step, prioritizing recoverability and validation over a one-way cutover.

Security Decisions

EXACT MATCHING

Exact hostname and package matching avoids silently widening a credential’s scope.

MEMORY-ONLY SESSION

The one-hour unlocked session trades repeated prompts for a bounded in-memory exposure window.

OPAQUE STORAGE

Server persistence is limited to encrypted records and the metadata required to operate the system.

PRIVATE SOURCE

The project source is private and no public repository is linked.

Limitations / Future Work

No external security audit or formal zero-knowledge certification has been performed.
An unlocked or compromised endpoint remains capable of exposing decrypted credentials.
Recovery and backup procedures require continued testing, versioning, and restore drills.
Future work includes broader interoperability testing and continued hardening of client boundaries.

Technical Stack

CRYPTOGRAPHY: AES-256-GCM · HKDF-SHA256 · Ed25519 · P-256
ANDROID: Android Keystore · Biometric gate · AutofillService · encrypted pending queue
DESKTOP / BROWSER: Linux Secret Service · Firefox Native Messaging
BOUNDARY / RECOVERY: WireGuard · opaque storage · offline recovery envelope · encrypted backups
SOURCE: Private; no public repository link.