
Ciphera ID
The sign-in
behind Ciphera.
Ciphera ID is infrastructure, not a product. It is how you sign in to Ciphera's own applications — with a password that never reaches our servers and a profile we cannot read.
01 · What it is
One account for our applications.
Every Ciphera application shares one account. You sign in once at id.ciphera.net and arrive back at the application you came from over OAuth 2.0 with mandatory PKCE. Today that means Pulse, with more of our own services to follow. Ciphera ID does the authentication ceremonies — sign in, sign up, recovery — and nothing else; your settings live in the application you are using.
It is not a general-purpose identity platform, and we would rather say so on this page than let you find out after a procurement call:
- No self-serve client registration — adding an application takes a database migration by us
- No OpenID Connect discovery document and no JWKS endpoint for third-party token verification
- No “Sign in with Ciphera” SDK, no social-login connectors, no SAML
- No plan, no price and no checkout — the billing tables were removed rather than left dormant
If you want to build on this model, the part you can actually use is Tessera — the OPAQUE implementation underneath Ciphera ID, published open-source under Apache-2.0.

Your password
••••••••••
Scrambled
a7f3c8e1b9d2...
Received
a7f3c8e1b9d2...
Opaque record
9f2c4e8a…b1d7
opaque credential · 9f2c4e8a…b1d7
Unreadable — even to us
02 · Authentication
Your password never leaves your device.
With OPAQUE(RFC 9807), your password is stretched on your device with Argon2id and proven to our servers without ever being sent. We store only an opaque credential record that can't be reversed into your password — so even a full database breach gives attackers nothing usable.
- OPAQUE (RFC 9807) — your password is never sent to our servers
- On-device Argon2id key stretching
- We store only an opaque credential record — no password, hash, or verifier
- No password reset — and account recovery is switched off while we finish it
To be precise about the last one: account recovery is unavailable today. We are completing a change to the recovery ceremony, and until it ships your password is the only way into your account — lose it and the account is gone. The 24-word phrase minted at signup is still worth keeping; it becomes the way back in once recovery is switched on.
03 · The vault
We do not know your name or your email address.
This is the part that surprises people, so it is worth being literal about it. The account table has no email column and no name column. Your name and email are sealed in a vault encrypted on your own device, under a key derived during the OPAQUE exchange that our servers never hold in usable form. To find your account at sign-in we use a blind index — a keyed hash of your email that identifies the row without revealing the address.
What an operator with full database access sees
One account row, in its entirety
- id
b7c1e0f4-2a58-4d19-9f3e-0c8a41d6b2ee
A UUID
- email_blind_index
4f9a2c81…e3d0
Keyed hash — not reversible to an address
- opaque_record
9f2c4e8a…b1d7
Credential record — no password inside it
- opaque_wrapped_key
c04b7e13…8a26
Inert without a key only your device derives
- encrypted_vault
a1d8…2f60
Ciphertext — your name and email, sealed
The trade-off is real and we take it deliberately: because we cannot read your address, we cannot reset your password for you, and a lawful order served on us returns ciphertext. The full account of what we can and cannot see is in what we see about you.
04 · Sessions
What happens after you sign in.
Applications never see your credentials. They receive a short-lived token over an OAuth 2.0 authorization-code flow, and they verify it without calling back to us on every request.
OAuth 2.0, PKCE mandatory
Every authorization-code flow requires PKCE with S256 — there is no downgrade path and no implicit flow. Access tokens live 15 minutes; refresh tokens rotate on use, and a reused token revokes the family.
A log you can read, on data we hash
Every sign-in, password change and second-factor event is recorded, and you can end any session from your account settings. Client IP addresses are HMAC-hashed before they are written — which is why the log shows a mask, not an address.
- TOTP two-factor authentication with any authenticator app
- Escalating lockout on repeated failures (15 min → 1 hour → 24 hours)
- A captcha challenge after three failed attempts
- Expired tokens and stale sessions cleaned up automatically

Data residency
Switzerland (FADP protected)
Token lifetime
15 min access, 30 day refresh
Compliance
GDPR, FADP, privacy by design
05 · Data residency
Hosted in Switzerland. Blind by design.
All identity data is stored under the Federal Act on Data Protection (FADP). Passwords use zero-knowledge OPAQUE auth, IPs are HMAC-hashed, and audit logs are batched asynchronously — privacy at every layer.
- Run on our own infrastructure — no third-party identity vendor holds your account
- IP addresses HMAC-hashed before storage
- Minimal metadata: no behavioral tracking
- Automatic token cleanup and session expiration
- Security alerts rate-limited to 1 per hour per user

06 · The code
You cannot buy this. You can read it.
Ciphera ID is an internal service, and it is staying that way. The cryptography underneath it is not: Tessera is the same OPAQUE code that verifies real Ciphera sign-ins, published under Apache-2.0 for anyone who wants to hold no passwords either.
Already have a Ciphera account? Sign in.