How we keep IPAuth itself defensible.

No passwords. Ever.

The single biggest source of compromised accounts in the field is password reuse and credential stuffing. We side-step the entire problem by never accepting a password.

Sign-in is one of three things:

• Magic link. One-time, 15-minute TTL, single-use. Token is 48 hex chars (192 bits of entropy). Consumed on first use; the row is marked used immediately to prevent replay.
• Google sign-in. OpenID Connect, OAuth 2.0 with PKCE (S256). Scope limited to openid email. We store the Google sub claim (a stable, opaque identifier) plus the verified email. We don't request profile photo, contacts, calendar, or anything else.
• GitHub sign-in. OAuth 2.0. Scope limited to read:user user:email. We store the GitHub user id plus a verified primary email. We never request access to your repositories.

Two-factor is mandatory.

Once you enroll TOTP, every subsequent sign-in (magic link OR OAuth) is gated by a 6-digit code from your authenticator app. TOTP follows RFC 6238 (HMAC-SHA1, 30-second period, 6 digits, ±1 step window for clock skew). We support any standards-compliant app: Google Authenticator, Authy, 1Password, Bitwarden, Microsoft Authenticator, etc.

The QR code on the enrollment page is rendered client-side from a vendored, self-hosted library (no third-party QR service receives your secret).

TOTP secrets are encrypted, not just hashed.

Unlike a password (where a one-way hash is enough for verification), a TOTP secret has to be readable in order to generate codes for comparison. So we encrypt it.

• AES-256-GCM with a 12-byte random IV per record and a 16-byte authentication tag. Authenticated encryption: tampering with the ciphertext breaks decryption, not just integrity.
• Key is a 32-byte value loaded from TOTP_KEY in config.env.php, which lives outside the document root and is readable only by the web user.
• Key rotation is supported with a one-pass re-encryption when needed.

Magic-link tokens, OAuth state nonces, and PKCE verifiers all use random_bytes() (libsodium CSPRNG on Linux). Never mt_rand.

Hardened session cookies.

• Secure (HTTPS only), HttpOnly (no JS access), SameSite=Lax (mitigates CSRF on cross-site navigation).
• Session ID is regenerated on every authentication transition (magic link verified, 2FA confirmed, OAuth callback completed). Session fixation is not a viable attack.
• 2FA-pending state and authenticated state are separate session keys. A pending-2FA session cannot reach gated pages.

Every state change is recorded.

We keep an append-only audit log of every state-changing action. Sign-ins, sign-outs, magic link requests, failed 2FA, pair create/update/delete, group create/delete, member add/remove, token rotation, SSO bind/unbind, bookmark emails. Each entry includes the user, the action, the target, the request IP (resolved through the CDN), and the user agent.

You can review your own audit trail in Account → Security log. We don't expose anyone else's entries to you, and we don't expose yours to anyone else.

Fronted by an independent CDN/WAF.

Public traffic to ipauth.net is fronted by NOC.org's CDN with a custom WAF ruleset and rate limiting. Origin Apache only accepts traffic from CDN edge IPs. The dashboard surface (/login, /dashboard, /account) sits behind an additional protected-URL allowlist enforced at the edge.

The free public flow (the /whitelist + /serverquery endpoints) is open by design, since their entire job is to be callable from anywhere a user's browser or a customer's server happens to be.

What we hold, and what we don't.

We hold the minimum required to make the product work:

• Your email, your magic link tokens (consumed quickly), your TOTP secret (encrypted), your OAuth provider id (if bound).
• The pairs you've created: name, optional recipient email, your generated keys, the most recent IP, the last-seen timestamp.
• Your access groups: name, description, API token, member list.
• Your audit log entries.

We don't store:

• Passwords. We don't have them.
• Anonymous (free flow) key pairs. Once issued, they live as flat files on the server keyed by random opaque IDs. There is no way for us to associate one with a person.
• Browser history, device fingerprints, or behavioral analytics. We use Plausible for aggregate page-view counts (privacy-friendly, no cookies).
• Anything we don't need.

Found something? Tell us.

If you find a vulnerability, please report it to security@ipauth.net. We'll acknowledge within 48 hours and work with you to validate, fix, and credit you (if you want).

We ask the standard things: don't access data that isn't yours, don't run automated scans that could affect availability, give us a reasonable window to fix before public disclosure.

This page describes our current implementation. As IPAuth evolves we update this writeup. Last reviewed 2026-05-31.