A password manager that cannot read your passwords.

The problem isn't that you forget passwords

It's that you have too many secrets, of too many shapes, and nowhere honest to put them.

A working developer or founder is carrying, at any moment: a few dozen logins, a handful of API keys, two-factor codes for the accounts that matter, a company card, a recovery phrase they can never lose, and a scattering of credential files — a service-account JSON, an AuthKey_XXXX.p8, a signing certificate. Those live in wildly different places. Logins end up in the browser. API keys end up in a .env that gets copied into Slack "just this once". The recovery phrase ends up in a Notes app. The key files end up in ~/Downloads, and then on a new laptop they're simply gone.

Every one of those is the same category of thing: a short string of bytes that grants access, that you must keep, and that you must never leak. The reason they end up in five different places is that most password managers only really model one shape — the website login — and everything else gets shoved into a free-text note.

So the goal here is narrow and specific: one encrypted place for every shape of secret, that opens on every device you own, and that stays readable to exactly one person.

What zero-knowledge actually means

The term gets used loosely enough to be nearly meaningless in marketing copy, so here is the concrete version.

Most services encrypt your data at rest. That's real, and it protects you if someone steals a hard drive out of a datacentre. But the service itself holds the key — it has to, because it decrypts your data to show it to you in a web page. Which means an administrator, a compromised server, a subpoena, or a bug in the wrong endpoint can all produce plaintext.

Zero-knowledge inverts that. The key is derived on your device and never leaves it. The server is handed ciphertext and asked to store it. It has no key, no way to derive one, and no way to tell whether a given blob is a password, a photo, or noise. When you read your vault, your own device does the decrypting.

This is why the PIN below is not a "password you log in with". It's an ingredient in the key. Nothing on any server ever compares it to anything.

How the encryption works

No hand-waving — these are the actual primitives, and they're identical on every device.

Deriving the key

Your key comes from two things: your Tieddr Account identity (a stable account id) and your 6-digit PIN. They're combined and run through PBKDF2-HMAC-SHA256 at 210,000 iterations — the OWASP recommendation — against a random 16-byte salt, producing a 256-bit key.

The iteration count is the point. A 6-digit PIN is only a million possibilities, which a computer would otherwise exhaust instantly. Forcing 210,000 hash rounds per guess makes brute force expensive, and because the key derivation happens on your device against ciphertext an attacker would first have to steal, there's no login endpoint to hammer. The account id being mixed in means two people with the same PIN never share a key.

Encrypting the data

Each entry is encrypted with AES-256-GCM — an authenticated cipher. That second word matters: GCM doesn't just hide the contents, it detects tampering. If a single byte of stored ciphertext is altered, decryption fails loudly rather than returning quietly corrupted data. Every single write gets a fresh random 12-byte nonce, so saving the same password twice produces two completely different ciphertexts, and nobody watching the store can infer anything from patterns.

What the server actually holds

That's the complete list. No titles, no URLs, no usernames, no searchable metadata — those all live inside the ciphertext. The store can tell you have some number of entries; it can't tell you have a Coinbase account.

Where the key lives

Only in memory, only while unlocked. It's never written to disk, never serialized, and never sent anywhere. Close the app and it's gone; you re-enter the PIN and it's derived again. On the desktop and in the browser it also auto-locks after inactivity, and at rest the local cache holds ciphertext only.

What it stores

Six shapes, because those are the six shapes that actually exist:

• Passwords — logins with a username, a site, and a generator. These autofill in the browser.
• Two-factor codes — proper TOTP (RFC 6238), the same standard an authenticator app uses, with a live countdown. Scan the QR once and the codes generate on-device forever, offline.
• Secrets — anything that's a name and a value: API keys, access tokens, account numbers, licence keys, an SSN. Tagged so you can find them.
• Key phrases — multi-line secrets that must survive intact: seed phrases, private keys, SSH and PGP keys, recovery codes.
• Wallet cards — card number, expiry and CVC, which autofill at checkout. Nothing is filled without you picking the card.
• Key files — the download-once credential files. This one gets its own section, below, because nobody else treats it as a first-class thing.

The key file problem

There's a category of secret that password managers have quietly ignored for a decade: the credential that arrives as a file, exactly once.

You've met all of them:

• A Google Cloud or Firebase service-account JSON, which the console generates, hands you, and never shows again.
• An App Store Connect AuthKey .p8, which Apple states plainly you can download a single time.
• A signing certificate or .pem keypair that took twenty minutes of ceremony to produce.

Lose one and you don't recover it — you revoke it, reissue it, and then update every deploy pipeline that referenced it. The standard workarounds are all bad: leave it in ~/Downloads and lose it with the laptop; commit it to a private repo and hope; email it to yourself and put a permanent secret in your mailbox forever; paste it into a notes app in plaintext.

Here, a key file is a first-class entry. You add the file, and its bytes are encrypted on your device and stored inside the entry itself, protected by exactly the same AES-256-GCM as your passwords. It syncs to every device you own. On the web you download the original file back, byte for byte; on your phone it sits under Secrets and you can copy its contents straight out.

Practical limit: these are credentials, not archives. A service-account JSON is around 2 KB and an AuthKey .p8 about 1.7 KB, so the cap sits far above anything you'd actually store.

How syncing works without trusting the sync

The device is always the source of truth for reading. The vault on your phone is a complete local copy, so opening it never waits on a network — it works on a plane, on hotel wifi, in a lift.

Syncing is a background reconcile against an encrypted mirror: your device pulls every blob for your account, merges by last-write-wins on each entry's own timestamp, and pushes anything it holds that's newer. Because every blob crossing the wire is ciphertext produced by a key the server has never seen, the mirror is a dumb store of opaque bytes. It could be operated by someone hostile and the guarantee wouldn't change.

The same design is what lets a second device join at all: it signs in with the same account, you enter the same PIN, the same key is reproduced, and the existing ciphertext simply opens.

Where it runs

• iPhone and Android — the primary app: everything, offline, plus system autofill.
• The browser — autofill and save as you go, including card autofill at checkout.
• Windows desktop — the full vault, with the local store additionally protected by the OS keystore.
• The web — sign in, unlock, read and add from any machine, with no install.

All four are the same vault. An entry saved in a browser is on your phone before you've picked it up, because they're not four products — they're four windows onto one encrypted store, and they all run identical cryptography.

The threat model, stated honestly

Security writing that only lists strengths is marketing. Here's both halves.

What this protects you from

• A breach of the sync store. An attacker gets ciphertext and nonces. Without your PIN there's nothing to read, and PBKDF2 at 210k iterations makes grinding it expensive.
• The operator. Nobody running the service can read your vault. Not by policy — by construction.
• Network interception. Everything is encrypted before it's sent, independent of TLS.
• Tampering. GCM authentication means modified ciphertext fails to decrypt rather than silently lying to you.
• Password reuse. The ordinary, boring, overwhelmingly common way people actually get compromised.

What it does not protect you from

• A compromised device. If malware has your unlocked phone, it can see what you can see. No vault design survives this.
• Forgetting your PIN. There is no recovery. This is the price of the guarantee above, and we'd rather say it plainly than bury it.
• Phishing your account. The vault protects stored secrets; it can't stop you typing your account credentials into a convincing fake.
• Someone watching you type. Shoulders and cameras remain out of scope.
• A secret already leaked. Storing a key safely doesn't un-leak a key you pasted into a public issue last year. Rotate it.

Versus the alternatives

Genuinely — for a lot of people, the browser's built-in store is fine, and it's certainly better than reuse. The differences worth knowing:

Privacy

The short version: the contents of your vault are mathematically unavailable to us, and we're not interested in the rest either.

• No trackers or ad SDKs in the apps.
• No selling data. There is no data to sell — see the whole page above.
• No plaintext, ever, anywhere. Not in the store, not in transit, not in a log.
• One identity across the suite, so signing in doesn't mean another account and another password.

See the privacy policy and terms for the formal version.

Questions people actually ask