Security
Security model
This page describes how NinjaBiba handles secrets today. It is product documentation, not a formal audit report or legal advice.
Client-side encryption
Vault plaintext is encrypted on your device before sync. The server stores an encrypted vault backup (ciphertext) so other devices can download and unlock it with your master password. Encryption keys are derived in the browser or app from that master password.
Master password never sent
Your vault master password is separate from your account password. It is used locally to unlock and is not uploaded. If you forget the master password, the server cannot recover decrypted vault contents.
What the server stores
- Account email and a hashed account password for sign-in.
- Encrypted vault ciphertext for sync.
- Optional authenticator (TOTP) secrets, encrypted at rest.
Auto-lock
After unlock, decrypted items stay in memory. Inactivity auto-lock (configurable on web) returns you to Unlock so plaintext does not remain available indefinitely. Manual lock and sign-out clear the same session state. The web app and Chrome extension lock independently.
Transport and sessions
Production uses HTTPS. Account access and refresh tokens are bearer tokens in memory (not cookies). Refreshing the web app signs you out of the in-memory session.
What this is not (yet)
- No independent third-party security audit published yet.
- No passkeys, sharing, or breach monitoring in the MVP.
- Rate limits are in-process on a single API instance.
Related reading: privacy policy, product overview.