Skip to content

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.

Zero-knowledgeOPAQUE (RFC 9807)Encrypted profile vaultSwiss-hosted

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.

The Ciphera ID sign-in screen — zero-knowledge OPAQUE authentication with passkey support
Your device

Your password

••••••••••

Scrambled

a7f3c8e1b9d2...

Encrypted in transit
Our server

Received

a7f3c8e1b9d2...

Opaque record

9f2c4e8a…b1d7

Stored in database

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
Zurich, Switzerland — where Ciphera data is hosted

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.