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.

Salted hashing

Secrets are stored with password_hash() (bcrypt) and verified in constant time — never unsalted, never reversible by lookup.

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

Each row is encoded independently, so a correct secret is unique and wrong entries are reliably rejected.

See the security checklist Request an implementation review