Security

Passwords are hashed with PBKDF2 (SHA-256) using a large iteration count and a unique per-user salt, so we store a verifier — never your actual password. Even with full database access, no one at Next Rally can read your password, and a stolen hash is impractical to reverse. Password comparisons are done in a timing-safe way.

• Login sessions use cryptographically signed tokens (HMAC via the Web Crypto API) with limited lifetimes, so a token can't be forged or silently extended.
• Optional two-factor login: a one-time passcode step, plus a trusted-device option so you're not prompted every time on your own phone.
• Sign in with Google is verified against Google's published keys on our server — we don't take the browser's word for who you are.
• Sensitive one-time codes and device tokens are stored so that they can't be read back or reused, and login attempts are limited to slow down guessing.

The high-privilege database key lives only on the server and is never sent to your browser. Every action that changes data goes through a server function that re-checks who you are and whether you're allowed to do it — being able to click a button in the app is never enough on its own. All input is validated at the boundary before anything touches the database.

• Row-level security is enabled on data that the app reads directly, so records are only visible under the conditions we define.
• Public/anonymous reads are restricted column by column — for example, phone numbers are never among the columns anonymous visitors can read.
• Secret tables (password verifiers, device tokens, one-time codes, rate-limit state) are locked to server-only access and are never exposed to the app or realtime updates.
• All writes are performed server-side with authorisation enforced in code.

• All traffic is served over HTTPS, with HSTS instructing browsers to refuse insecure connections.
• Responses set protective headers: no MIME-type sniffing, anti-clickjacking (framing denied), a strict referrer policy, and a permissions policy that disables device capabilities the app doesn't use (camera, microphone, geolocation, payment, USB).

• Authentication and sync endpoints are rate-limited to resist brute force and spam.
• In shared games, a device can claim only one name, keeping rosters honest.
• Skill-rating and stats calculations are designed to be repeatable and never double-counted, so results can't be quietly inflated.

Privileged administrator actions are written to an append-only audit log. Server errors are captured so we can find and fix problems; error reports carry technical context, not your personal profile data.

Credentials and API keys are never committed to our codebase — they're supplied as protected environment secrets and read only on the server at request time. Development and production data are isolated from each other.

If you believe you've found a security issue, please tell us privately before disclosing it publicly, and give us reasonable time to fix it. Email security@talnt.fit. We appreciate responsible disclosure.