Why Qypher is secure.

Credentials are machine-generated tokens, not human-memorized passwords. The risks intrinsic to memorized secrets — reuse, guessing, phishing of a remembered secret — never arise in the first place.

Qypher's database never stores credentials in a recoverable form. What it keeps is only a one-way hash — a transformed value from which the original cannot be computed back. So even if the database were exposed, no usable credential could be extracted from it. Personal information such as names and addresses is also stored fully encrypted, so even in a leak its contents could not be read directly.

Credentials are produced by a cryptographically secure pseudo-random generator (CSPRNG) and never derived from predictable inputs such as timestamps, so they cannot be enumerated or reproduced by guessing.

The token carried in the QR code is both encrypted and integrity-protected. Any altered or forged token is reliably rejected during verification, and a valid token cannot be assembled from partial information.

Multiple components are validated together as a single unit. Knowing only part of it never passes, leaving no room to attack components independently.

A login result carries the information of which site it is meant for, sealed so it cannot be altered afterward. The receiving site checks that the seal is genuine before accepting it. This means an attacker cannot grab the result in transit and reuse it on a different (fake) site.

By default, a site receives only the minimum: the Qypher ID and the result of the age check (yes/no). The exact age and date of birth are never sent — only whether the user meets the site's age requirement (the result is included by default so that age verification can't be defeated simply by refusing to send it). Whether anything beyond that is shared is decided only when both the site's request and the user's consent are present; data the user has not approved is never sent. Each site's requested data and terms are shown at login so the user can review and consent. (Note: how a site handles data once shared is that site's own responsibility — something Qypher cannot guarantee.)

Reissuing a Qypher card makes the previous one invalid the instant it is issued. If a card is lost, or anything seems off, the user can reissue it at any time to invalidate the previous credential. Even in the event of a leak, the window of exposure is kept to a minimum.

Sessions are validated server-side, and no trust-bearing secret is held on the client. They expire automatically after a period of inactivity. By design, nothing worth stealing is left on the client.

The API is protected by multiple layers — automated abuse detection, reputation-based blocking, and bot filtering (specific criteria and thresholds are not disclosed).

Qypher determines age from the registered date of birth, but passes to each site only the result of whether the user meets that site's age requirement (yes/no) — not the exact age. The date of birth and the exact age stay inside Qypher and never reach the site (sending the exact age each time could let a site infer the birthday from the value changing, so only the result is shared). This means sites don't have to collect or manage the date of birth or age themselves.
In addition, each site can set its own age threshold and choose whether users below it are simply blocked (age restriction) or allowed with guardian confirmation (guardian confirmation is the baseline for under-13s).
(Note: this is a determination based on the registered date of birth, not an age check against official documents.)

Rather than home-grown crypto, we use globally established encryption — the same kind trusted by government agencies and the financial industry. These methods have withstood scrutiny by experts worldwide for many years. All traffic is protected by TLS, and we never rely on obscurity alone for security.