GitHub Try it now

Security model

Precise, not loud.

Security products earn trust by being clear about their limits, not by making big claims. Here is exactly what PassNumber is designed to do, what it leaves to you, and what it does not pretend to do.

The method helps with

  • ✓ Shoulder-surfing. The visible input changes every login, so watching once tells an observer nothing about next time.
  • ✓ Replayed keystrokes. A captured entry is tied to one shuffle and won't authenticate again.
  • ✓ Plaintext exposure. Only a salted hash is stored; symbols and positions never are.
  • ✓ Casual brute force. Combined with per-account lockout, repeated guessing is throttled.

You must implement

  • ! HTTPS / TLS on every request, without exception.
  • ! Security headers including a strict Content-Security-Policy.
  • ! Rate limiting at the IP / network level, beyond per-account lockout.
  • ! Recovery & logging. Account recovery, audit logs, monitoring, and a professional review before production.

Threat model

What it does — and does not — defend against.

In scope

An attacker who can observe a single login (over your shoulder, a camera, or a keylogger capturing one session) should not be able to reuse what they saw. That is the core design goal, and the reshuffle achieves it.

Out of scope

  • A man-in-the-middle on an unencrypted connection — this is why HTTPS is mandatory, not optional.
  • An attacker who can record many logins over time and perform statistical analysis. Larger grids raise this cost; nothing makes it zero.
  • Phishing of the symbols themselves via a fake site — standard anti-phishing measures still apply.
  • Compromise of the server or database — mitigated by salted hashing, but server security remains the implementer's job.
What we don't claim. PassNumber is a demonstration of an authentication method, not an audited, certified, or production-ready security product. We don't claim it is "unhackable", "100% secure", or that it prevents man-in-the-middle attacks. Anyone telling you an auth method is perfect is selling something.

How the demo is built

The reference implementation's choices.

Both login methods — Classic and Sequence — run on the same engine and the same storage rules.

Salted, slow hashing

Secrets are stored as PBKDF2-SHA256 (310,000 iterations) with a per-account random salt and an optional server-side pepper, compared in constant time. Hashes are versioned and upgrade automatically at login.

Prepared statements

Every database query uses PDO prepared statements. No query is built by string concatenation, so injection is closed off.

CSRF & sessions

Every form carries a CSRF token; session cookies are HttpOnly and SameSite, and become Secure automatically over HTTPS.

Account lockout

After repeated failed attempts an account locks for a cooldown window, throttling guessing at the account level.

No credentials in code

The demo uses SQLite — a local file — so there is no database password to commit, leak, or rotate.

Collision-free secret

Every choice is encoded as a labelled token in a fixed order (no arithmetic, no overlapping values), so two different secrets can never produce the same stored hash.

Deterministic verification

By default the server builds exactly one candidate from your input and compares one hash. Any accepted variant — like the optional rotating start row — is an explicit opt-in, with its guessing-strength cost (~2 bits) stated at sign-up. No silent acceptance sets.

See the security checklist Request an implementation review