System Requirements Document for password-authentication

1. Introduction

password-authentication is a local, self-contained laboratory instrument for auditing password authentication against a target the operator controls. It is built for one technical operator working on their own machine, deliberately breaking authentication in a controlled environment in order to learn how it fails.

The product's intent is to make a password-auditing exercise legible and honest from end to end: the operator configures a deliberately vulnerable local test authentication service, supplies test usernames and a locally generated test password list, optionally sets concurrency, generates or reads candidate passwords, dispatches each candidate through a worker pool against the controlled service, analyzes the controlled application's response to decide accept or reject, and reviews attempts/second, number tested, the successful laboratory credential, error counts, and runtime/logs.

The audience is a single active human role — the Laboratory Operator — a technical practitioner running an exercise against a service they own and control. The product is not a commercial pentest platform, not a multi-tenant service, and not a tool aimed at third-party systems.

2. System Overview

The system is a local laboratory bench with a browser-based console and a local backend. The operator configures a run, produces candidates, watches a queue and worker pool process them against a deliberately vulnerable local test authentication service, and reads the analyzed verdicts and results.

Current delivery consists of seven first-party pages — Landing, Run Configuration, Candidates, Queue, Run, Analysis, and Results — all owned by the application and all reachable without an access requirement. The single active human actor is the Laboratory Operator. The deliberately vulnerable local test authentication service is an external, operator-controlled system that the product points at; it is not a page and not a persona.

Accepted behavior covers: run input configuration (controlled target, test username(s), locally generated test password list, optional concurrency settings); a candidate generator that generates or reads candidate passwords using dictionary, rule-based, and exhaustive combination approaches; an attempt engine that sends each candidate to the deliberately vulnerable local test authentication service and records whether the laboratory service accepts or rejects it; a response analyzer that determines success/failure from the controlled test application's response while accounting for the false positives that come from relying only on HTTP status codes; a concurrency/queue layer where a worker pool processes candidates and a central queue tracks pending, successful, and failed attempts; and results reporting of attempts/second, number tested, successful laboratory credential, error counts, and runtime/logs.

Narrow exclusions: the product is scoped to laboratory testing against a deliberately vulnerable local test authentication service that the operator controls. Test passwords must come from a locally generated test password list. Response analysis must use the controlled application's response and must not rely only on HTTP status codes.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a local application: a first-party console (browser UI) plus a local backend that performs candidate generation, queueing, worker-pool dispatch, attempt execution, response analysis, and results/logging. The backend is required because the attempt engine, worker pool, and central queue are long-running, stateful processes that the operator starts, watches, and stops.

Access ownership. Every page in the current contract is application-owned and carries no access requirement. The product is a single-operator local instrument; no accepted journey requires private, resumable, actor-bound state that must be protected from another human, and no accepted source statement establishes application-owned identity, sign-in, or differentiated permissions. Access to the console is therefore open within the local deployment, and no account-management capability is part of this product.

Target ownership. The deliberately vulnerable local test authentication service is external to the product and owned by the operator. The product never provisions, hosts, or hardens that service; it only sends candidates to it and reads its responses. The operator is responsible for the service being deliberately vulnerable, local, and under their control.

Current vs. future. Everything in this document is current. No future-horizon requirements were accepted in the authoritative thread; nothing here is deferred.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information/state: The product's purpose stated plainly — a local laboratory bench for auditing password authentication against a deliberately vulnerable local test authentication service the operator controls. The current run-state lamp (IDLE / READY / RUNNING) is visible in the top bar.
• Primary action: Open Run Configuration.
• Supporting actions: Read the constraint statement (local, operator-controlled, deliberately vulnerable target only).
• Domain entities: Run state; controlled target host string.
• Component responsibilities: Top bar with wordmark, local target host string in monospace, and the 3-state pixel status lamp. Full-width pixel instrument panel: stacked uppercase headline, a 2px black rule spanning the viewport, and a wide white outlined panel holding the 96px pixel padlock-and-keys composition beside one monospace paragraph of body copy and the black square button.
• States: Loading — static content, no data fetch required; lamp renders IDLE. Empty — no run configured yet; the button is the only path forward. Success — operator proceeds to Run Configuration. Error — none specific to this page; if the local backend is unreachable, the lamp holds IDLE and the button remains available. Recovery — operator retries opening Run Configuration.

Run Configuration

• Information/state: Current values for the controlled target, test username(s), locally generated test password list, and optional concurrency settings; validation state for each; readiness of the run.
• Primary action: Save the run configuration and mark the run READY.
• Supporting actions: Add/remove test usernames; point at or load the locally generated test password list; set or clear concurrency settings; clear the configuration.
• Domain entities: Controlled target (host/endpoint of the deliberately vulnerable local test authentication service); test username(s); locally generated test password list; concurrency settings.
• Component responsibilities: Persistent run rail (target, usernames, wordlist, concurrency) with 1px black rules between label/value pairs; input fields with 2px black outlines and 4px radius; validation messages; the save key.
• States: Loading — reading any previously entered local configuration. Empty — no target, no usernames, no wordlist; save is unavailable. Success — configuration saved, run state moves to READY, lamp turns amber. Error — missing target, no test username, no locally generated test password list, or invalid concurrency value; each is reported against its own field. Recovery — operator corrects the flagged field and saves again.

Candidates

• Information/state: The candidate set currently produced or read, its source approach, and its size.
• Primary action: Generate or read candidate passwords.
• Supporting actions: Choose the approach — dictionary, rule-based, or exhaustive combinations; read candidates from the locally generated test password list; inspect the produced candidate list.
• Domain entities: Candidate password; generation approach (dictionary / rule-based / exhaustive combinations); locally generated test password list.
• Component responsibilities: Approach selector; source selector for reading the locally generated test password list; candidate list rendered in monospace with wrapping rather than truncation; candidate count readout in VT323.
• States: Loading — generation or read in progress. Empty — no candidates produced yet, or the selected source yielded none. Success — candidate set produced and counted. Error — unreadable or missing locally generated test password list, or an approach that cannot produce candidates from the given inputs. Recovery — operator selects a different approach or corrects the wordlist source and regenerates.

Queue

• Information/state: The central queue as a three-column ruled ledger — PENDING / ACCEPTED / REJECTED — with the in-flight row marked, plus worker-pool occupancy.
• Primary action: Observe queue movement and worker-pool processing.
• Supporting actions: Inspect an individual queued candidate; read the pending, successful, and failed counts.
• Domain entities: Queue entry; queue state (pending / successful / failed); worker.
• Component responsibilities: Three-column ledger with hairline black rules and no card chrome; in-flight row in the informational signal colour; discrete 8px block meters for worker occupancy; counters in VT323.
• States: Loading — queue being populated from the candidate set. Empty — no candidates queued. Success — entries move between columns as the response analyzer returns verdicts. Error — a worker fails to dispatch or the queue stalls; the affected entry is marked and counted. Recovery — operator restarts the run or re-queues the affected entries.

Run

• Information/state: Run state (IDLE / READY / RUNNING), the controlled target in use, elapsed runtime, and live attempt counters.
• Primary action: Start the attempt engine against the deliberately vulnerable local test service.
• Supporting actions: Stop the run; observe each candidate being sent and its recorded accept or reject outcome.
• Domain entities: Attempt; attempt outcome (accepted / rejected); run state; runtime.
• Component responsibilities: Run-state lamp; start and stop keys as square black keys with a 4px hard offset shadow that collapses on press; live counters (attempts/second, number tested, errors, runtime) in VT323, tabular, stacked in a tight-left column; log stream with a blinking cursor.
• States: Loading — run starting, workers spinning up. Empty — no run started. Success — run completes; every candidate has a recorded outcome. Error — the controlled service is unreachable or returns an unreadable response; the attempt is recorded as an error and counted. Recovery — operator verifies the controlled local service is running and reachable, then restarts the run.

Analysis

• Information/state: For each attempt, the raw controlled response beside the derived verdict, with explicit marking where status-code-only analysis would have produced a false positive.
• Primary action: Review the response analyzer's determination of success or failure from the controlled test application's response.
• Supporting actions: Inspect the raw response body excerpt for an attempt; inspect the verdict; identify attempts flagged as status-code-only false positives.
• Domain entities: Controlled response (status code and response body); verdict (success / failure); false-positive flag.
• Component responsibilities: Side-by-side panel — monospace response body excerpt on the left, verdict and pixel magnifier pictogram on the right, whose lens fills with the signal colour when status-code-only analysis would have been a false positive.
• States: Loading — responses being analyzed. Empty — no attempts analyzed yet. Success — every attempt carries a verdict derived from the controlled application's response. Error — a response cannot be parsed; the attempt is flagged and counted as an error rather than silently judged. Recovery — operator inspects the raw response and the flagged attempt, then re-runs or excludes it.

Results

• Information/state: Attempts/second, number tested, the successful laboratory credential, error counts, and runtime/logs.
• Primary action: Review the completed run's results.
• Supporting actions: Read the log stream; read the successful laboratory credential when one was found; read error counts and runtime.
• Domain entities: Attempts/second; number tested; successful laboratory credential; error count; runtime; log line.
• Component responsibilities: Labelled results table with hairline rules (not a grid of identical cards); large VT323 numerals for attempts/second, number tested, errors, and runtime; the successful laboratory credential presented with a 2px accent rule and a 3-frame pixel stamp; log panel with appended lines and a blinking cursor.
• States: Loading — results being aggregated at run end. Empty — no run has completed. Success — results and logs available; a successful laboratory credential is shown if one was found. Error — the run ended with errors; error counts are shown and the affected attempts are identifiable in the logs. Recovery — operator reads the logs, corrects the configuration or the controlled service, and runs again.

3. Functional Requirements

FR-1 — Configure the run inputs. As a Laboratory Operator, I should configure the target I control, my test username(s), a locally generated test password list, and optional concurrency settings, so that a run is fully specified before any attempt is made.

• Provenance: explicit.
• Lifecycle: initiated by the Laboratory Operator on Run Configuration; input is the controlled target, test username(s), the locally generated test password list, and optional concurrency settings; observable result is a saved configuration and a run state of READY.
• Access state: no access requirement.
• Failure/recovery: a missing target, missing test username, missing locally generated test password list, or invalid concurrency value is reported against its own field; the operator corrects it and saves again.
• Continuation: the operator proceeds to Candidates.

FR-2 — Generate or read candidate passwords. As a Laboratory Operator, I should generate or read candidate passwords using dictionary, rule-based, or exhaustive combination approaches, so that I have a candidate set to test.

• Provenance: explicit.
• Lifecycle: initiated by the Laboratory Operator on Candidates; input is the chosen approach and the locally generated test password list; observable result is a produced and counted candidate set.
• Access state: no access requirement.
• Failure/recovery: an unreadable or missing locally generated test password list, or an approach that cannot produce candidates from the given inputs, is reported; the operator changes the approach or corrects the source and regenerates.
• Continuation: the candidate set is queued on Queue.

FR-3 — Send each candidate to the deliberately vulnerable local test authentication service. As a Laboratory Operator, I should have each candidate sent to a deliberately vulnerable local test authentication service, so that the laboratory service's accept or reject behavior is exercised.

• Provenance: explicit.
• Lifecycle: initiated by the Laboratory Operator on Run; input is each queued candidate and the configured controlled target; observable result is a recorded accept or reject outcome for that candidate.
• Access state: no access requirement.
• Failure/recovery: if the controlled service is unreachable or returns an unreadable response, the attempt is recorded as an error and counted rather than silently dropped; the operator verifies the controlled local service and restarts the run.
• Continuation: recorded outcomes flow to Analysis.

FR-4 — Record whether the laboratory service accepts or rejects each candidate. As a Laboratory Operator, I should have the attempt engine record whether the laboratory service accepts or rejects each candidate, so that every attempt has a durable outcome.

• Provenance: explicit.
• Lifecycle: performed by the attempt engine during a run on Run; input is the controlled service's response to each candidate; observable result is a per-candidate recorded outcome visible in the queue ledger and the results.
• Access state: no access requirement.
• Failure/recovery: an attempt with no readable outcome is recorded as an error and counted.
• Continuation: outcomes are analyzed on Analysis and aggregated on Results.

FR-5 — Determine success/failure from the controlled test application's response. As a Laboratory Operator, I should have the response analyzer determine success or failure from the controlled test application's response, so that verdicts reflect the application's actual behavior.

• Provenance: explicit.
• Lifecycle: performed by the response analyzer on Analysis; input is the controlled application's response (status code and response contents); observable result is a verdict per attempt.
• Access state: no access requirement.
• Failure/recovery: an unparseable response is flagged and counted as an error rather than judged.
• Continuation: verdicts move queue entries between the ACCEPTED and REJECTED columns and feed the results.

FR-6 — Account for status-code-only false positives. As a Laboratory Operator, I should be able to see where relying only on HTTP status codes would have produced a false positive, so that I do not trust a status-code-only verdict.

• Provenance: explicit.
• Lifecycle: performed by the response analyzer on Analysis; input is the raw controlled response beside the derived verdict; observable result is an explicit false-positive marking on the affected attempt.
• Access state: no access requirement.
• Failure/recovery: if the raw response cannot be retained for comparison, the attempt is flagged rather than presented as a confident verdict.
• Continuation: the operator inspects the flagged attempt and decides whether to re-run or exclude it.

FR-7 — Process candidates through a worker pool. As a Laboratory Operator, I should have a worker pool process candidates, so that attempts proceed concurrently under my optional concurrency settings.

• Provenance: explicit.
• Lifecycle: initiated by the Laboratory Operator starting a run on Run; input is the queued candidate set and the concurrency settings; observable result is workers consuming the queue and the run-state lamp showing RUNNING.
• Access state: no access requirement.
• Failure/recovery: a worker that fails to dispatch or stalls is surfaced on Queue and counted as an error; the operator restarts the run or re-queues the affected entries.
• Continuation: processed candidates move through the queue ledger to Analysis and Results.

FR-8 — Track pending, successful, and failed attempts in a central queue. As a Laboratory Operator, I should have a central queue track pending, successful, and failed attempts, so that I can see the state of the whole run at a glance.

• Provenance: explicit.
• Lifecycle: maintained by the queue on Queue; input is the candidate set and the analyzer's verdicts; observable result is a three-column ledger (PENDING / ACCEPTED / REJECTED) with the in-flight row marked.
• Access state: no access requirement.
• Failure/recovery: an entry that cannot be dispatched or resolved is marked and counted rather than left ambiguous.
• Continuation: the operator reads the ledger while the run proceeds and after it completes.

FR-9 — Report attempts/second. As a Laboratory Operator, I should see attempts per second, so that I know the throughput of the run.

• Provenance: explicit.
• Lifecycle: produced by the run and shown on Results (and live on Run); input is completed attempts and elapsed runtime; observable result is a tabular attempts/second figure.
• Access state: no access requirement.
• Failure/recovery: with no completed attempts the figure reads zero rather than blank.
• Continuation: the operator compares throughput across runs.

FR-10 — Report the number tested. As a Laboratory Operator, I should see the number tested, so that I know how much of the candidate set was exercised.

• Provenance: explicit.
• Lifecycle: produced by the run and shown on Results; input is the count of attempts made; observable result is a tabular number-tested figure.
• Access state: no access requirement.
• Failure/recovery: with no run completed the figure reads zero.
• Continuation: the operator reads it alongside attempts/second and error counts.

FR-11 — Report the successful laboratory credential. As a Laboratory Operator, I should see the successful laboratory credential when one is found, so that I know which candidate the laboratory service accepted.

• Provenance: explicit.
• Lifecycle: produced by the run and shown on Results; input is the accepted candidate and its test username; observable result is the successful laboratory credential presented with a 2px accent rule and a 3-frame pixel stamp.
• Access state: no access requirement.
• Failure/recovery: when no candidate is accepted, the result states that no successful laboratory credential was found rather than showing an empty slot.
• Continuation: the operator records the finding and ends the exercise.

FR-12 — Report error counts. As a Laboratory Operator, I should see error counts, so that I can distinguish genuine rejects from failures of the run itself.

• Provenance: explicit.
• Lifecycle: produced by the run and shown on Results; input is attempts that failed to produce a readable outcome; observable result is a tabular error count.
• Access state: no access requirement.
• Failure/recovery: errors are counted and identifiable in the logs rather than folded into the reject count.
• Continuation: the operator reads the logs and decides whether to re-run.

FR-13 — Report runtime and logs. As a Laboratory Operator, I should see runtime and logs, so that I can reconstruct what happened during the run.

• Provenance: explicit.
• Lifecycle: produced by the run and shown on Results; input is run start/stop times and appended log lines; observable result is a runtime figure and a readable log stream.
• Access state: no access requirement.
• Failure/recovery: log lines wrap or scroll rather than being truncated or ellipsised.
• Continuation: the operator uses the logs to correct configuration or the controlled service and run again.

FR-14 — Keep the target deliberately vulnerable, local, and operator-controlled. As a Laboratory Operator, I should only ever point the tool at a deliberately vulnerable local test authentication service that I control, so that the exercise stays a laboratory exercise.

• Provenance: explicit (hard constraint).
• Lifecycle: enforced at configuration on Run Configuration and stated plainly on Landing; input is the controlled target; observable result is that the tool is scoped to laboratory testing against that controlled local service.
• Access state: no access requirement.
• Failure/recovery: a target that is not the operator's controlled local test service is outside the product's scope; the operator corrects the target.
• Continuation: the run proceeds only against the controlled local service.

FR-15 — Source test passwords from a locally generated test password list. As a Laboratory Operator, I should supply test passwords from a locally generated test password list, so that the exercise uses locally generated test material.

• Provenance: explicit (hard constraint).
• Lifecycle: enforced at configuration on Run Configuration and at generation on Candidates; input is the locally generated test password list; observable result is that candidates derive from that local list.
• Access state: no access requirement.
• Failure/recovery: a missing or unreadable locally generated test password list is reported and the run cannot be marked READY.
• Continuation: the operator supplies the list and proceeds.

FR-16 — Never rely only on HTTP status codes. As a Laboratory Operator, I should have response analysis use the controlled application's response rather than only HTTP status codes, so that verdicts are not false positives.

• Provenance: explicit (hard constraint).
• Lifecycle: enforced by the response analyzer on Analysis; input is the controlled application's response contents as well as its status code; observable result is a verdict that accounts for response contents and marks status-code-only false positives.
• Access state: no access requirement.
• Failure/recovery: where response contents are unavailable, the attempt is flagged rather than judged on status code alone.
• Continuation: the operator reviews the flagged attempt on Analysis.

4. User Personas

Laboratory Operator

Product context. The Laboratory Operator is the single active human role in this product. They work locally, on their own machine, against a deliberately vulnerable local test authentication service that they themselves control. They are running a laboratory exercise: they want to see how authentication fails, and they want the instrument to be honest about what it observed.

Primary goal. To run a complete password-auditing exercise against their own controlled local test authentication service and come away with a trustworthy result: how many candidates were tested, how fast, which candidate the laboratory service accepted (if any), how many attempts errored, and what the runtime and logs say happened.

Distinct accepted responsibilities.

• Configuring the run: the controlled target, test username(s), the locally generated test password list, and optional concurrency settings.
• Producing candidates: generating or reading candidate passwords via dictionary, rule-based, or exhaustive combination approaches.
• Running the attempt engine: sending each candidate to the deliberately vulnerable local test authentication service and having accept/reject recorded.
• Reading the analysis: reviewing the response analyzer's verdicts derived from the controlled application's response, including where status-code-only analysis would have been a false positive.
• Watching the queue and worker pool: pending, successful, and failed attempts, and worker-pool processing.
• Reviewing results: attempts/second, number tested, the successful laboratory credential, error counts, and runtime/logs.

Relevant inputs and decisions. The operator decides which controlled local target to point at, which test usernames to test, which locally generated test password list to use, which candidate-generation approach to apply, and whether to set concurrency settings at all (they are optional). They decide when to start and stop a run, and they decide whether a flagged false-positive attempt warrants a re-run.

Interactions with other accepted participants. The Laboratory Operator is the only accepted human participant. The deliberately vulnerable local test authentication service is an external, operator-controlled system that the product sends candidates to and reads responses from; it is not a persona and does not act within the product. No other human participant is affected by the run.

Observable success. The run completes with every candidate carrying a recorded outcome; the queue ledger shows pending, successful, and failed attempts resolved; the analysis shows verdicts derived from the controlled application's response with false-positive risk named rather than hidden; and the results show attempts/second, number tested, the successful laboratory credential when one was found, error counts, and runtime/logs.

5. Core User Flows

Flow 1 — Configure a run against the controlled local test service

1. The Laboratory Operator opens Landing and reads the plain statement that this tool only ever points at a deliberately vulnerable local service the operator controls. The run-state lamp reads IDLE.
2. The operator activates OPEN RUN CONFIGURATION and arrives at Run Configuration.
3. The operator enters the target they control — the local endpoint of the deliberately vulnerable test authentication service.
4. The operator enters one or more test usernames.
5. The operator points at the locally generated test password list.
6. Optionally, the operator sets concurrency settings. If they leave them unset, the run proceeds with the product's default worker behavior.
7. The operator saves the configuration. The run state moves to READY and the lamp turns amber.
8. Failure/recovery: if the target is missing, no test username is given, the locally generated test password list is missing or unreadable, or a concurrency value is invalid, the affected field is flagged and the run does not become READY. The operator corrects the field and saves again.
9. Continuation: the operator moves to Candidates.

Flow 2 — Produce the candidate set

1. From Run Configuration, the Laboratory Operator moves to Candidates.
2. The operator chooses a generation approach: dictionary, rule-based, or exhaustive combinations — or chooses to read candidates from the locally generated test password list.
3. The operator starts generation or reading. The candidate list is produced and counted.
4. Failure/recovery: if the locally generated test password list cannot be read, or the chosen approach cannot produce candidates from the given inputs, the page reports it. The operator selects a different approach or corrects the source and regenerates.
5. Continuation: the candidate set is queued, and the operator moves to Queue.

Flow 3 — Watch the queue and worker pool

1. On Queue, the Laboratory Operator sees the central queue as a three-column ruled ledger: PENDING / ACCEPTED / REJECTED, with the in-flight row marked.
2. The operator sees worker-pool occupancy as discrete block meters and the pending, successful, and failed counts.
3. As the run proceeds, entries move between columns instantly when the response analyzer returns a verdict.
4. Failure/recovery: if a worker fails to dispatch or the queue stalls, the affected entry is marked and counted. The operator restarts the run or re-queues the affected entries.
5. Continuation: the operator moves to Run to start or supervise the attempt engine.

Flow 4 — Run the attempt engine against the deliberately vulnerable local test service

1. On Run, the Laboratory Operator confirms the controlled target in use and starts the attempt engine.
2. The run-state lamp turns green and blinks while the worker pool is active; the runtime counter advances.
3. Each candidate is sent to the deliberately vulnerable local test authentication service, and the attempt engine records whether the laboratory service accepts or rejects it.
4. Live counters show attempts/second, number tested, errors, and runtime.
5. Failure/recovery: if the controlled service is unreachable or returns an unreadable response, the attempt is recorded as an error and counted rather than silently dropped. The operator verifies that the controlled local service is running and reachable, then restarts the run.
6. The operator stops the run when the candidate set is exhausted or when they choose to stop.
7. Continuation: recorded outcomes flow to Analysis.

Flow 5 — Analyze the controlled application's response

1. On Analysis, the Laboratory Operator reviews each attempt with the raw controlled response beside the derived verdict: the monospace response body excerpt on the left, the verdict on the right.
2. Where relying only on HTTP status codes would have produced a false positive, the pixel magnifier's lens fills with the signal colour and the attempt is explicitly marked.
3. Failure/recovery: if a response cannot be parsed, the attempt is flagged and counted as an error rather than judged. The operator inspects the raw response and the flagged attempt, then re-runs or excludes it.
4. Continuation: verdicts feed the queue ledger and the results.

Flow 6 — Review results and logs

1. On Results, the Laboratory Operator reads attempts/second, number tested, error counts, and runtime as large tabular numerals.
2. If a candidate was accepted, the successful laboratory credential is shown with a 2px accent rule and a 3-frame pixel stamp. If none was accepted, the result states that no successful laboratory credential was found.
3. The operator reads the log stream, where lines append with a blinking cursor and wrap or scroll rather than being truncated.
4. Failure/recovery: if the run ended with errors, the error count is shown and the affected attempts are identifiable in the logs. The operator corrects the configuration or the controlled service and runs again.
5. Continuation: the operator records the finding and ends the exercise, or returns to Run Configuration for another run.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Susan Kare; the headline idea is charming clarity for a laboratory instrument — a well-built instrument with a personality, legible at a glance, honest about state, never pretending to be more than it is.

Colour tokens (light mode).

Proportion: ~70% pale grey ground, ~22% white panels, ~6% black rules and type mass, ~2% signal pixels. Every signal colour appears only as a shape no larger than a 16px icon or a 2px rule — never as a fill or wash. The interface stays monochrome until something actually happens. No blue or indigo primary; no blue-on-white button; the only action colour is black.

Typography.

• Headings: VT323, uppercase, 0.04em tracking, no bold (single weight), sized by scale not weight. Used at large sizes for numerals, section titles, and status readouts.
• Body, labels, inputs, log lines: IBM Plex Mono at 13–15px with 1.6 line-height.
• Scale (1.25 modular with a pixel-display step): 96 / 72 / 48 / 28 / 20 / 15 / 13.
• Hero display: 96px desktop, 56px mobile — clamp(56px, 8vw, 96px).
• Section titles 28px; panel headers 20px uppercase; body and labels 15px; secondary 13px.
• Line-height 1.6 for reading text, 1.0 for display numerals so stacked counters form a tight column.
• Numerals are always tabular so counters never jitter.

Shape language. Hard 2px black outlines on every panel, input, and button. No soft shadows, no blur, no gradients anywhere. Corners are square (0px radius) for panels and 4px for buttons and inputs, so controls read as pressable keys. A 1px black rule separates every label/value pair. Icons are drawn on a 16px pixel grid with 1px black strokes and a single flat signal-colour fill. Progress and meter bars are made of discrete 8px blocks, not continuous fills. Focus states are a 2px accent outline offset by 2px — visible, never a glow.

Layout. Desktop-lab layout at 1280px: a 64px-tall top bar carrying the wordmark, the local target host string in monospace, and the run-state pixel lamp; below it a 12-column grid where the left 3 columns are the persistent run rail (target, usernames, wordlist, concurrency) and the right 9 columns are the active surface, switched by a tab strip: Candidates / Queue / Run / Analysis / Results. Panels sit on the grey ground with 24px gutters and never bleed. At 768px the rail collapses to a horizontal settings strip above the surface. At 375px everything is one column, panels full-width with 16px gutters, the tab strip becomes a horizontally scrollable row of 44px-tall keys that never clip their labels, and every value cell wraps rather than truncating. Numeric results are laid out as a labelled table with hairline rules, not as a grid of identical cards.

Imagery. No photography. The imagery is the interface itself plus a small library of 16px and 32px pixel pictograms drawn on the grid: a key, a padlock (open and closed), a queue stack, a worker gear, a stopwatch, a magnifier over a response body, a clipboard of logs, a warning triangle. Plus one larger 96px pixel composition used on the landing hero: a padlock with a comb of candidate keys marching into it, drawn in flat black with a single red pixel where the key turns. Diagrams are drawn in the same pixel grid so the whole product looks cut from one bitmap.

7. Signature Design Concept

The landing first screen is not a centred SaaS hero. It is a full-width pixel instrument panel.

On the left, a 96px (56px on mobile) VT323 headline set in two stacked uppercase lines — LAB AUTH BENCH over AGAINST YOUR OWN TARGET — flush left, black on the pale grey ground, occupying roughly 9 of 12 columns and running edge to edge of the content grid. Beneath it, a 2px black rule spans the full viewport width.

Under the rule, a single wide white panel with a 2px black outline holds the 96px pixel padlock-and-keys composition on the left — a padlock with a comb of candidate keys marching into it, flat black with a single red pixel where the key turns — and, on the right, one monospace paragraph of 15px body copy explaining that this tool only ever points at a deliberately vulnerable local service the operator controls, plus a black square button reading OPEN RUN CONFIGURATION with a hard 2px black shadow offset 4px down-right.

In the top-right corner of the viewport, a 3-state pixel lamp (IDLE / READY / RUNNING) sits in the top bar. Nothing is centred, nothing floats, no gradient appears anywhere. The concept recomposes only accepted content, states, and controls: the constraint statement, the run-state lamp, and the single path into Run Configuration.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief. The focal subject is the 96px pixel padlock-and-keys composition: a padlock with a comb of candidate keys marching into it, drawn in flat black with a single red pixel where the key turns. The input→transformation→outcome thesis is: candidate keys advance toward the padlock (input) → the comb reaches the lock and the key turns (transformation) → a single red pixel marks the turn, and the run-state lamp in the top bar holds its current colour (outcome). This uses only accepted behavior — candidates, the controlled target, and the run-state lamp — and invents no new capability. The motion vocabulary is frame-by-frame, never eased: discrete steps, no interpolation, no smooth transitions. The composed first frame shows the padlock closed, the key comb at rest, the headline fully set, the 2px rule drawn, and the lamp grey at IDLE. The reduced-motion state holds the composition still: the lamp holds steady on its current colour, counters update without the step, and the stamp appears already filled.

Product-wide motion. Frame-by-frame, never eased. The run lamp blinks at 1Hz while the worker pool is active. Counters tick by swapping digits with a 60ms step and no interpolation. A successful laboratory credential lands as a 3-frame stamp (outline, filled, outline) with a single 2px accent rule drawing under the row. Queue rows move between pending/success/failed columns by instant reposition, not by sliding. Log lines append with a 40ms cursor blink. With prefers-reduced-motion, the lamp holds steady on its current colour, counters update without the step, and the stamp appears already filled.

9. Non-Functional Requirements

NFR-1 — Local, self-contained operation. The product runs locally for a single operator. The attempt engine, worker pool, and central queue execute against a deliberately vulnerable local test authentication service the operator controls. Provenance: explicit (hard constraint). Rationale: the product is scoped to laboratory testing against a controlled local service.

NFR-2 — Locally generated test password material. Test passwords come from a locally generated test password list. Provenance: explicit (hard constraint). Rationale: the exercise uses locally generated test material.

NFR-3 — Response analysis fidelity. Response analysis determines success/failure from the controlled test application's response and does not rely only on HTTP status codes, because status-code-only analysis can produce false positives. Provenance: explicit (hard constraint). Rationale: verdicts must reflect the controlled application's actual behavior.

NFR-4 — Honest state reporting. Run state, queue state, counters, and verdicts are reported truthfully: errors are counted separately from rejects, unparseable responses are flagged rather than judged, and a status-code-only false positive is named rather than hidden. Provenance: explicit. Rationale: the operator must be able to trust the instrument's readouts.

NFR-5 — No truncation of operational values. Usernames, host strings, candidate passwords, and log lines wrap or scroll; they are never truncated or ellipsised. Provenance: explicit (creative direction). Rationale: the operator must be able to read the exact value that was tested.

NFR-6 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, and no other element covers any part of them. Provenance: explicit (creative direction). Rationale: legibility is a hard requirement of the instrument.

NFR-7 — Reduced-motion support. With prefers-reduced-motion, the run lamp holds steady on its current colour, counters update without the digit step, and the credential stamp appears already filled. Provenance: explicit (creative direction). Rationale: motion is decorative state emphasis, not information the operator depends on.

NFR-8 — Tabular numerals. All counters and numeric readouts use tabular numerals so values never jitter as they update. Provenance: explicit (creative direction). Rationale: fast-refreshing counters must remain readable.

10. Tech Stack

• Frontend: React (browser console), styled to the creative direction — VT323 and IBM Plex Mono, hard 2px black outlines, square panels, discrete 8px block meters, no gradients or blur.
• Backend: Python with FastAPI, providing the candidate generator, the attempt engine, the response analyzer, the worker pool, the central queue, and results/logging.
• Storage: local storage for run configuration, candidate sets, queue state, attempt outcomes, and logs, sufficient to resume reading results after a run completes.
• Packaging: Docker with docker-compose for running the console and backend together on the operator's machine.
• Kubernetes: not required. The product is a single-operator local instrument; no accepted requirement calls for cluster deployment.

Provenance: the authoritative thread specifies no technology choices. These are coherent defaults for a local, stateful, fast-refreshing console with a long-running backend, and are labeled as defaults rather than user-specified choices.

11. Assumptions and Constraints

Constraints (binding).

• The target must be a deliberately vulnerable local test authentication service that the operator controls; the tool is scoped to laboratory testing against that controlled local service.
• Test passwords must come from a locally generated test password list.
• The response analyzer must determine success/failure from the controlled test application's response; relying only on HTTP status codes can produce false positives.

Assumptions (narrow, labeled).

• Assumption: the operator has already stood up the deliberately vulnerable local test authentication service and knows its local endpoint. The product does not provision or host it.
• Assumption: the locally generated test password list exists on the operator's machine and is readable by the product.
• Assumption: concurrency settings are optional; when unset, the product uses its own default worker behavior.
• Assumption: the product is used by a single operator at a time on a local machine; no concurrent multi-operator use is required.
• Assumption: no application identity, sign-in, or differentiated permissions are required, because no accepted journey requires private, resumable, actor-bound state and no accepted source statement establishes them.
• Assumption: the tech stack in Section 10 is a coherent default, not a user-specified choice.

Exclusions.

• No targeting of systems the operator does not control.
• No provisioning, hosting, or hardening of the deliberately vulnerable test authentication service.
• No account management, sign-in, or role-based permission controls.
• No future-horizon features were accepted; nothing is deferred.

12. Glossary

• Laboratory Operator — the single active human role; the technical practitioner who configures and runs the exercise against their own controlled local test authentication service.
• Controlled target — the local endpoint of the deliberately vulnerable test authentication service that the operator owns and controls.
• Deliberately vulnerable local test authentication service — the external, operator-controlled service the product sends candidates to and reads responses from. It is not part of the product.
• Test username — a username the operator supplies to be tested against the controlled target.
• Locally generated test password list — the local wordlist from which test passwords are drawn; the required source of test password material.
• Candidate password — a password produced or read by the candidate generator, to be sent to the controlled target.
• Candidate generator — the component that generates or reads candidate passwords using dictionary, rule-based, or exhaustive combination approaches.
• Dictionary approach — generating candidates by reading entries from the locally generated test password list.
• Rule-based approach — generating candidates by applying transformation rules to source words.
• Exhaustive combination approach — generating candidates by enumerating combinations of characters or source fragments.
• Attempt engine — the component that sends each candidate to the deliberately vulnerable local test authentication service and records whether the laboratory service accepts or rejects it.
• Response analyzer — the component that determines success or failure from the controlled test application's response, accounting for the false positives that status-code-only analysis can produce.
• False positive (status-code-only) — a verdict of success derived only from an HTTP status code that the controlled application's response contents do not support.
• Worker pool — the set of workers that process candidates from the central queue.
• Central queue — the structure that tracks pending, successful, and failed attempts.
• Attempts/second — the throughput figure for a run.
• Number tested — the count of attempts made in a run.
• Successful laboratory credential — the candidate (with its test username) that the controlled laboratory service accepted.
• Error count — the count of attempts that failed to produce a readable outcome.
• Runtime/logs — the elapsed run time and the appended log stream for a run.
• Run state — IDLE, READY, or RUNNING, shown by the top-bar pixel lamp.