SafePass

A conventional password vault or recovery service can concentrate complete secrets, encryption keys or recovery authority in one place. SafePass explores a local-first design in which the server authenticates accounts and stores only opaque ciphertext, while no single stored share is enough to reconstruct a protected credential.

Trust boundary: the master key and plaintext credentials never go to the API. AES-256-GCM binds every share to its account, vault, recovery set and policy; plaintext is reconstructed only in the unlocked client and is cleared or hidden as quickly as practical.

• Each protected secret uses a fixed 2-of-2 Shamir policy: encrypted share 1 stays in the device vault and encrypted share 2 is stored by the authenticated FastAPI service.
• Envelope encryption separates the account password, master key and random Vault Encryption Key. Changing the master key re-wraps the vault key without rewriting every secret.
• Native clients use an owner-scoped SQLite vault; web clients use origin-private or compatibility browser storage. Encrypted .spvault backups provide explicit cross-device portability.
• Rotating refresh tokens, optional device-bound biometric unlock, automatic locking, screen protection, clipboard cleanup and privacy-preserving security history reduce exposure around the encrypted core.

• A compromised API exposes account-scoped ciphertext and only one encrypted Shamir share—not a plaintext credential, master key, recovery key or complete share pair.
• Recovery requires the authenticated account, the local encrypted share and an unlocked vault. Missing uploads, revision conflicts and interrupted rotations fail without silently committing partial local state.
• A separate 2-of-2 recovery kit can reset a forgotten master key on a device that still holds its matching local recovery share; encrypted backups support device migration without exporting plaintext secrets.

Honest limitation: SafePass is a security prototype, not a production password manager. Its 2-of-2 design cannot recover from both a lost device and a lost recovery kit, and it does not make a compromised endpoint trustworthy. Production use still requires hardened infrastructure, TLS, shared rate limiting, monitored backups, dependency remediation and independent cryptographic review.

Evidence status: The current Expo 57 / React Native 0.86 client and FastAPI prototype include automated frontend and backend security tests. A project website is available; no public repository is currently linked, and production readiness is not claimed.