How SafeLane keeps your passwords safe — and why a leak of our servers is not a leak of your passwords.
SafeLane uses end-to-end encryption: the keys that decrypt your vault never leave your device. Our servers store only ciphertext. Even a complete server compromise leaves your vault unreadable — not because we promise to keep it safe, but because we are mathematically incapable of opening it.
What follows is the long version. The key hierarchy, with the cryptographic primitives named. A precise inventory of what our servers do and do not see. Our threat model, including the threats we cannot defend against. And the choices we made — including a few we are not yet happy with.
§ 2 Hierarchy
The key hierarchy, drawn out.
From your passphrase to the plaintext, one diagram. The dashed line is the network boundary; everything above it happens in your browser. Only ciphertext crosses2.
2Plus your email, the KDF parameters needed to reproduce derivation, and item-sizes & timestamps. The exact server-visible inventory follows.
§ 3 Visibility
The ledger.
Two columns. Everything our servers can see is on the left. Everything they cannot is on the right. There is nothing in the middle.
What the server can see
Necessary for the service to function.
+
Your email address
You gave it to sign up. Used for sign-in and security alerts only.
+
KDF parameters & salt
Needed to reproduce key derivation on a new device.
+
Wrapped DEK
Encrypted under your KEK. Useless without your passphrase.
+
Encrypted item blobs
Opaque ciphertext. Sizes and timestamps are visible.
+
Per-device session metadata
For sign-in alerts and revocation.
What the server cannot see
By construction, not policy.
—
Your master passphrase
Never transmitted. Never typed into a server form.
—
The unwrapped DEK
Reconstructed only in your browser, in memory.
—
Item plaintext
Including item names, URLs and usernames.
—
Search queries
Search runs locally over decrypted items.
—
Which items you opened
Open events are never reported back.
§ 4 Threat model
What SafeLane defends against — and what it doesn't.
A threat model is only useful when it admits its limits. Here are ours.
Defended
Server compromise.
An attacker with full access to our database walks away with ciphertext, KDF parameters, and your email. They cannot read a single item.
Network interception.
All transport uses TLS, with HSTS. Items are also encrypted at the application layer, so a broken TLS handshake still leaks only ciphertext.
Stolen device.
The vault locks automatically after inactivity (default: 15 minutes). The unlocked DEK is held in memory only, and is zeroed on lock.
Account hijack.
TOTP-based 2FA, passkey-protected vault unlock (WebAuthn with PRF), sign-in email alerts, and per-device session monitoring. Compromising the auth key alone does not yield the KEK.
Not defended
Malware on your unlocked device.
No password manager defends against a keylogger or memory scraper running with your privileges. Keep your machines clean.
A rubber-hose attacker.
If somebody can compel you to type your passphrase, we cannot help. We have no recovery, deliberately.
A forgotten passphrase.
There is no back-door, and so no recovery. Write your passphrase down somewhere safe — a sealed envelope in a sock drawer is acceptable; a sticky note on the monitor is not.
Targeted side-channel attacks.
An attacker measuring your CPU power-draw while you unlock is outside our model. If you require this level of opsec, you also require advice we cannot give over a website.
§ 5 Primitives
The cryptographic choices, with their parameters.
Stored per-user so we can raise the work factor over time without invalidating existing vaults.
Key derivation
Argon2id
t = 3 · m = 64 MiB · p = 4 · salt = 32 B
OWASP-2023 minimum. Tuned to ≈ 250 ms on a modern device. Each parameter is stored alongside the user so we can migrate them upwards.
Symmetric encryption
AES-256-GCM
iv = 96 b (random) · tag = 128 b
Random IV per encryption. Auth tag verified before decryption is even attempted. Versioned envelope, so we can migrate later.
Randomness
WebCrypto CSPRNG
crypto.getRandomValues · OS-sourced entropy
No app-level PRNG. We delegate to the platform — which delegates to the kernel.
Asymmetric (share)
X25519 + HKDF-SHA-256
for item-sharing only — never your full vault
When you share an item with family, we wrap the item's key under the recipient's X25519 public key. We never derive a shared key for the vault itself.
What we don't use, and why: no proprietary primitives; no AES-CTR-then-HMAC compose-it-yourself constructions (GCM gives us authenticated encryption in one step); no PBKDF2 (memory-hard is the standard now); no recovery questions (a back door for us is a back door for everyone).
§ 6 Audits
Verification, by people who are not us.
SafeLane commissions an annual third-party security audit covering the cryptographic implementation, the server architecture, and the end-to-end story we tell on this page. The first audit is scheduled for Q3 2026; we will publish the full report — including any issues found — when it lands.
If you'd like to subscribe to be notified, leave us an address. We won't write more than four times a year.
§ 7 Warrant canary
What we have not been asked to do.
As of 17 May 2026, SafeLane has received:
·Zero National Security Letters from any government
·Zero gag orders from any court
·Zero requests from any law-enforcement agency to insert backdoors, decrypt user data, or modify SafeLane software
·Zero subpoenas served on SafeLane to date
This statement is refreshed quarterly. If it disappears or materially changes without explanation, treat that as a signal. The current canary text is also published on the transparency page.
§ 8 Disclosure
Found a flaw?
Please email info@usesafelane.com with reproduction steps, affected versions, and any mitigation you can suggest. Don't publicly disclose for 90 days while we ship a fix. The machine-readable contact is also at /.well-known/security.txt.