Product Requirements

nviaOTP is a security engineering lab for one-time passwords. Its tagline — “OTP engineering, from RFC to attack surface” — is also its scope: the site starts at the arithmetic of RFC 4226 and RFC 6238 and ends at detection rules and incident reviews for authentication failures. It is written for backend engineers who implement verifiers, security engineers who threat-model login and recovery, and SREs who keep authentication observable in production. It is not a vendor quick-start, not a marketing site and not a general security course.

The product promise is that every claim can be checked on the page. Where a chapter says dynamic truncation selects four bytes at an offset taken from the low nibble of the last byte, a workbench shows those bytes highlighted. Where a chapter says a token bucket closes the fixed-window boundary leak, a playground runs both against the same burst and prints the counts. Demos that disagree with the lesson are treated as bugs of the same severity as factual errors in prose.

Audience and jobs to be done

• Backend engineer: implement HOTP/TOTP correctly, provision secrets, choose verification windows, add replay protection and step-up flows without breaking users.
• Security engineer: model SIM swap, real-time relay, MFA fatigue and pumping against a concrete flow; choose and justify controls; score residual risk consistently.
• SRE / detection engineer: decide what auth telemetry to emit without logging secrets or excess personal data; write detections with baselines that survive seasonality; run blameless reviews.

Home — the lab bench

The first screen is split. On the left: the headline, a one-paragraph subhead and two calls to action, “Enter the lab” and “Browse series”. On the right: a live TOTP card. It generates a fresh 160-bit secret in the visitor’s browser, displays it in base32, and shows a six-digit code that rotates every 30 seconds with a circular countdown ring. The caption states plainly that this is RFC 6238 running in the browser. Below the fold the home page shows, in order: the “New chapters this week” rail, a “Continue learning” strip when local progress exists, three role-based learning paths, a library preview with progress rings, and a custom oscilloscope-style illustration of an authentication signal.

Curriculum

Six series, thirty-one chapters. Each chapter carries at least 900 words of prose, at least one inline diagram with an accessible label, and a three-question quiz with instant feedback. Reading time is computed from the actual prose word count divided by 200; it is never typed by hand.

• 1 · OTP Cryptography Internals (5) — shared secrets, HOTP truncation, TOTP time steps, secret provisioning, verification policy.
• 2 · Phishing-Resistant Auth (5) — why phished codes fail, origin binding, the WebAuthn ceremony, passkeys in practice, a step-up ladder.
• 3 · Threat Modeling OTP Flows (6) — assets and boundaries, SIM swap, AitM relay, push bombing, pumping, scoring mitigations.
• 4 · Rate Limiting & Abuse Economics (5) — limiter algorithms, keys and collisions, lockouts and delays, attack cost, protecting honest users.
• 5 · Risk-Based Step-Up & Account Recovery (5) — privacy-aware signals, policy matrices, step-up UX, recovery hardening, failure modes.
• 6 · Detection Engineering for Auth (5) — telemetry without PII, rules that do not page for noise, baselines, alert design, post-incident review.

Prerequisites form a graph rendered on every series page: series 2 and 3 require series 1; series 4 requires 1 and 3; series 5 requires 3; series 6 requires 4.

Lab modules

Four instruments are listed under the Lab navigation item and embedded in the chapter each one illustrates. The TOTP workbench exposes every intermediate value of HOTP and TOTP and recomputes the published RFC test vectors on load so the visitor can verify the implementation. The attack simulator fast-forwards four scripted attacks and lets the visitor toggle five defenses. The WebAuthn ceremony mock performs real P-256 signatures with a key generated in the tab, and runs the nine relying-party checks with pass/fail per step. The policy engine evaluates a JSON rules file against sample sessions and names the rule that fired.

Functional requirements

• FR-1 The home TOTP card must produce codes identical to a standards-compliant authenticator for the displayed secret, rotate on 30-second boundaries and animate its ring continuously.
• FR-2 “New chapters this week” must be computed at runtime from each chapter’s publish date against the visitor’s current date; no fixed dates in code.
• FR-3 “Continue learning” appears only when local progress exists and links to the first unfinished chapter of the most recent series.
• FR-4 Library cards show level, chapter count and a progress ring; topic chips and a live search filter the grid.
• FR-5 Series pages show the ordered chapter list with completion state and the interactive prerequisite graph: hover highlights the ancestor chain, click navigates.
• FR-6 Chapter pages provide a sticky chapter checklist, a scroll-spy table of contents, previous/next links and a discussion thread.
• FR-7 At least twelve code playgrounds run learner code 450 ms after typing stops, in an isolated worker, and stop runaway code after six seconds with an inline message.
• FR-8 Playgrounds that make claims assert them and print PASS or FAIL; the shipped starter code must print only PASS.
• FR-9 At least six before→after diff widgets animate removed and added lines.
• FR-10 Scrolling past 80% of a chapter marks it complete, plays the gold check and confetti, a soft chime after a user gesture, and a toast; all rings update.
• FR-11 Comments are shared across readers, need only a typed display name, support one level of replies, can be reported, and are hidden after three distinct reports.
• FR-12 Comments enforce a minimum length of 15 characters and per-browser rate limits; the product ships with zero comments.
• FR-13 Dim mode toggles from the header and persists across visits.
• FR-14 Every route has a unique title and description for search and link previews.

Non-goals

• Accounts, paid tiers or tracking pixels.
• Chapters on message delivery, carrier routing, webhook signing or compliance programmes — those belong to sister properties and get at most a sentence.
• Real network calls from learner code; the sandbox has no network.

Success measures

Because the product deliberately avoids analytics on learners, success is measured through content and quality signals the team can observe directly: all RFC vectors green on every release; zero FAIL lines in shipped playgrounds; every chapter above the word and diagram minimums; zero untriaged reported comments older than a week; and qualitative feedback in the discussion threads. A release that breaks any of these is rolled back rather than patched forward.