Zero-Knowledge Encryption, Explained Without the Marketing
What zero-knowledge actually means in a password manager, which guarantees it does and does not give you, and how to tell a real claim from a slogan.
Read Article
Your passwords. Your vault. Your privacy.
A privacy-focused password manager for Android, desktop and iOS, built on Kotlin Multiplatform with an offline-first vault.
Overview
NexusPass is a password manager for people who would rather not hand their credentials to a service they have to trust. The vault is a file on your own device. There is no account to create, nothing to sign in to, and no server that holds a copy of your data.
It is built as a single Kotlin Multiplatform codebase targeting Android, desktop and iOS. That is not a technical flourish — it means the parts that matter most, the ones that decide how a vault is unlocked and what sits in memory while it is open, exist in exactly one place and are reviewed once.
Status: in active development. NexusPass has not been publicly released. The pages here describe how it is designed and built; they will be updated with store links and verified specifics as it ships.
The Problem
Most people arrive at a password manager after being told to. What they meet is usually one of two disappointments.
The first is complexity. Enterprise-grade managers carry organisations, policies, sharing hierarchies and admin consoles. Someone who wants to stop reusing the same password across thirty sites has to walk past all of it.
The second is the account. Signing up before storing a single password is a strange first step for a product whose entire premise is secrecy. It also quietly changes the question. Instead of is my vault safe? it becomes do I trust this company, its hosting, its staff, and everyone who acquires it later?
There is a third problem that gets less attention: the second app. Storing one-time codes somewhere else means every login is a swap between two applications, and it means the recovery codes for that second app end up somewhere careless.
The Solution
NexusPass answers those three problems directly.
No account. The vault is created locally and unlocked locally. There is nothing to register and no credential to lose.
One place for the whole login. Passwords and their TOTP codes live on the same entry, so signing in somewhere is one screen rather than a hop between apps.
Separate vaults instead of one large one. Personal, work and shared credentials can be kept apart, so unlocking one does not put everything on screen at once.
The same app everywhere. Android, desktop and iOS run the same shared code, so a habit learned on one is not relearned on the next.
Group credentials into separate vaults — personal, work, shared — so unlocking one does not expose everything at once.
Usernames, passwords, URLs, notes and custom fields, with a generator for new credentials.
Time-based one-time passwords stored beside the credential they belong to, so a login is one screen rather than two apps.
Learn how this worksReusable shapes for cards, identities, notes and logins, so the same fields are not rebuilt by hand each time.
Unlock with the device's own biometric prompt after the vault has been opened once with the master password.
Find an entry by name, username, URL or tag without scrolling a list.
Store recovery codes and key files alongside the entry they belong to, inside the encrypted vault.
The vault re-locks on a timer and when the app moves to the background.
Secrets stay masked until revealed, and the app's contents are hidden from the OS task switcher.
UX & Design
A password manager is used in a hurry, often while something else is blocked on it. That shapes most of the design decisions.
Reading a secret is deliberate. Values stay masked until you ask for them, and the app's contents are hidden from the OS task switcher, so an over-the-shoulder glance or a screen recording does not capture a vault.
Locking is automatic. The vault re-locks on a timer and whenever the app goes to the background. There is no state where an unattended device is left open.
Search before hierarchy. Most sessions are "find this one entry", so search is the fastest path, and folders are there for the times it is not.
One design system across targets. Because the UI is Compose Multiplatform, the desktop build is not a second-class port — it is the same components laid out for a larger window.
A single Kotlin Multiplatform codebase with one shared domain layer. Only the thinnest platform layer differs per target, which keeps security-critical logic written once.
Compose Multiplatform screens shared across Android, desktop and iOS.
Holds screen state and exposes it as observable flows. No platform types cross this boundary.
One class per user-visible action, so business rules can be tested without a UI or a database.
The single entry point to stored data, hiding whether a value came from memory or from disk.
Local persistence and the cryptographic boundary. Plaintext secrets never leave this layer.
The vault lives on the device. There is no account to create and no server holding a copy.
The vault file is encrypted on disk; the app works with decrypted data only in memory while unlocked.
Unlock keys are held by the Android Keystore and the iOS Keychain rather than written into app storage.
Auto-lock on a timer and on backgrounding, so an unattended unlocked device does not stay unlocked.
Deciding what a password manager should not do: no account, no sync requirement, no upsell.
Choosing Kotlin Multiplatform so the security-critical layer is written and reviewed once.
Learn how this worksBuilding the shared component set before the screens, so every surface reads the same.
Working out where keys live, when the vault unlocks, and what is in memory at any moment.
Learn how this worksBringing the desktop and iOS targets up on the same shared code as Android.
Unit tests around the crypto boundary and the repository, and UI tests for the unlock flow.
Packaging, store review and the first public build.
Feedback on a project, bug reports and suggestions are always welcome.