Is my portfolio actually private?
Yes, at the level we can prove in the browser. Your holdings are
encrypted on your device with AES-256-GCM before they ever leave.
The server sees only a blob of ciphertext plus a monotonic sequence
number. The key never touches the network.
What does the server see?
- Your username, for login.
- A scrypt verifier of whatever you use to log in — either a
passphrase or the secret your passkey derives (see “are logins
safe”). The passphrase or passkey itself never leaves your
device.
- If you signed up with a passkey: the credential ID, so we can
prompt the right one next time. Never the private key.
- Your email, only if you chose to add one.
- Your encrypted vault — unreadable without your vault passphrase.
- An audit trail: when your vault changed, from roughly
which region, and how big it got. Never what changed.
Login vs unlock — why are there two steps?
Because they do different jobs and only one of them can involve the
server.
-
Login is between you and the server. It proves
you’re allowed to have the encrypted file, and the server hands
it over. A login passkey or login passphrase
unlocks this step.
-
Unlock is entirely in your browser. It decrypts
the file the server just handed you — the server never sees the
key. An unlock passkey or vault passphrase
unlocks this step.
So there can be up to four credentials on a full account: a login
passkey, a login passphrase, an unlock passkey, and a vault
passphrase. Most people set one on each side and forget about it.
Settings groups them under “Login — how you prove it’s you” and
“Unlock — how the vault decrypts” for exactly this reason.
Practical rule of thumb: if a screen is titled Log in,
it wants a login credential. If it’s titled Unlock your
vault, it wants an unlock credential. Adding a passkey on
one side doesn’t add it on the other — they’re independent.
Passkey or passphrase — which should I pick?
Default to passkey for both sides. Your device
(Face ID, Touch ID, Windows Hello, a hardware key) holds a private
key that never leaves it; on login the browser asks the device for
a per-site secret, and the same trick works client-side to unwrap
the vault key. Nothing to remember, nothing to phish.
Pick passphrase if you’d rather memorise a phrase,
or if you plan to sign in from browsers where passkey roaming is
awkward. You can add either one to an existing account later from
Settings, so this isn’t a one-way door.
You can also mix: passkey on the login side, passphrase on the
unlock side (or vice versa). They’re independent.
I added a passkey but it’s still asking for a passphrase
You added it on one side; the other side doesn’t have one yet.
The most common case: you added a login passkey, signed
in with a tap, and then the unlock screen asked for your
passphrase because the vault itself doesn’t know about a passkey
yet.
Fix it in Settings → Unlock — how the vault decrypts
→ Add passkey for unlocking. That wraps the vault key with
a passkey-derived secret and appends it to the vault’s unlockers,
so next time the unlock screen offers a passkey button instead of
the passphrase field.
Restoring a backup carries over whatever unlockers the backup had,
which is usually just the original passphrase. Add an unlock
passkey once, after restore, and you’re done.
What if I lose the device with my passkey?
If your passkey syncs (iCloud Keychain, Google Password Manager,
1Password, etc.) it comes back with your account. If it doesn't —
say it lived only on one hardware key — the account is
stuck. StealthLedger can't reset it because it has no
shared secret to reset to.
Practical mitigations, in order of effort:
- Enrol a second passkey on another device (phone + laptop, or a
hardware key you keep in a drawer). Add it any time from
Settings → Login.
- Add a memorised login passphrase as a fallback from Settings →
Login. You can do this after signup — it's not a one-time
decision.
- Write down your vault recovery code either way; it's
what protects the actual holdings, and it's paper-only.
Are logins safe if the server gets dumped?
The server never stores your login secret — passphrase or passkey.
It stores a scrypt verifier with N=65536, r=8, p=1
(about 64 MB per guess). A stolen database gives an attacker no
help decrypting any vault — vault contents need the vault
passphrase, which the server has never seen.
Passkey accounts are quietly stronger against dumps because the
secret going into scrypt is a 32-byte high-entropy value from the
authenticator, not something a human typed — offline cracking has
essentially nothing to guess against.
What if I forget my vault passphrase?
Your holdings are gone. Not “wait a while” gone — gone. There is no
reset flow because there is no reset key. Set up a
recovery code when you create the vault; that’s the escape
hatch.
Restoring a backup — what should I expect?
A backup file is your encrypted vault as it was on the day you
exported it: same vaultId, same unlockers, same holdings.
Restoring it into a new account overwrites whatever vault that
account currently has and hands you back the old one. You’ll unlock
it with the backup’s vault passphrase or recovery
code — not the passphrase you just used to sign up.
The usual flow when moving between accounts or coming from the old
single-tenant version:
- Sign up on the new site (any username you like).
- Log in, then head to Settings → Restore from backup…
and pick the JSON file.
- Confirm the “different vault” warning; the app locks itself.
- Unlock with the passphrase (or recovery code) that opened the
backup back when it was made.
- Optional but recommended: add an unlock passkey so future
unlocks are one tap.
If the restore screen refuses your file, the fastest reset is
Settings → Forget access token, log in again with the
account passphrase, then retry. That gets you into a clean state
where the client and server agree on which account you’re acting
as.
What if I forget my login passphrase (or lose my passkey)?
Right now, the account is stuck. If we later add an email-based
reset it will only reset the login, not decrypt anything —
the vault contents are still gated by the vault passphrase.
What if the site owner turns evil?
Because the site serves you the JavaScript that touches your vault
passphrase, a determined operator could push a poisoned build. We
mitigate that with a strict Content-Security-Policy (no inline
scripts, no third-party origins), a small hand-written codebase,
and a published crypto spec you can diff against what your browser
loads. The application itself is proprietary; the encryption
layer, threat model, and audit-log format are open for review.
How is this different from Bitwarden or 1Password?
Same idea, narrower scope. Purpose-built encrypted spreadsheet
for crypto holdings. Fewer features, smaller codebase. Bitwarden
and 1Password are fully open source; StealthLedger publishes its
crypto layer and threat model rather than the whole app.
Can I delete my account?
Yes, any time. Settings → Account → Danger zone → Delete my
account. Type your username to confirm. It's a hard
delete — encrypted vault, sessions, audit log, all of
it. No grace period, no undo. If you want a copy of your data
first, export it from Settings before you press the button.
Do you have telemetry or analytics?
None. No trackers, no pings, no third-party scripts.
