CAPTCHA-X: LLM & Keystroke Dynamics

• CAPTCHA-X is a hybrid security system that integrates LLM-generated cognitive questions with keystroke-dynamics analysis for distinguishing humans from bots.
• It generates everyday common-sense and arithmetic questions using Google Gemini, hashes the correct answer with SHA-256, and analyzes typing rhythms to verify submissions.
• Its dual-layer approach thwarts paste-based and scripted attacks, achieving 100% success in human trials while blocking basic automated bots.

CAPTCHA-X is a hybrid CAPTCHA prototype that combines LLM-generated cognitive questions with keystroke-dynamics analysis to distinguish human users from bots. In the 2025 implementation, the backend uses Google Gemini to generate simple common-sense or basic-math question–answer pairs, hashes the correct answer with SHA-256, and sends only the question and hash to the browser; the client then captures keystroke timing and paste events while the answer is typed. A submission is accepted only if the answer is correct, no paste event is observed, and the typing rhythm satisfies empirically chosen human-like thresholds, making CAPTCHA-X a dual-layer fusion of semantic challenge solving and behavioral biometrics (Nia, 29 Sep 2025).

1. Motivation and conceptual basis

CAPTCHA-X is motivated by two persistent weaknesses in mainstream CAPTCHA deployment. First, conventional text and image CAPTCHAs have become vulnerable to OCR, deep learning, computer vision systems, and automated browser interaction. Second, stronger challenges often worsen usability, accessibility, and privacy. A large empirical study of contemporary third-party CAPTCHA providers and solving services concluded that most current CAPTCHAs are vulnerable to both human solvers and automated solvers, and argued that new CAPTCHAs based on hard AI problems and behavior analysis are needed (Jin et al., 2023).

The prototype addresses this by verifying both what a user knows and how the user acts. The cognitive layer uses simple, everyday questions such as “What color is the sky on a clear day?” or “What is 5 + 3?”, while the behavioral layer measures the timing irregularity of typing. This replaces the classical assumption that distorted perception tasks remain difficult for machines with a combined assumption: semantic answering and realistic human motor variability must both be reproduced in a single short interaction (Nia, 29 Sep 2025).

This design also responds to a broader usability problem. User-perception studies report that current CAPTCHAs are often frustrating, increasingly difficult, and especially problematic on mobile devices or under accessibility constraints (Reddy et al., 2024). CAPTCHA-X therefore aims to keep the explicit challenge cognitively trivial while shifting part of the discrimination burden to passive behavioral measurement.

2. Architecture and challenge generation

The system follows a client–server model. The backend holds the LLM API key, calls the LLM, generates the cognitive question and correct answer, computes the SHA-256 hash of the answer, and sends only the question and hash to the client. The plaintext answer is discarded before anything is sent to the browser. On submission, the server receives the user’s plaintext answer, keystroke-derived features, and a paste flag, and performs final classification (Nia, 29 Sep 2025).

The LLM is instructed through structured prompt engineering to return JSON with keys question and answer. Prompt randomization produces challenges across domains such as colors, shapes, object properties, and basic arithmetic. The examples given in the prototype include:

• “What color is the sky on a clear day?” → “blue”
• “What is 5 + 3?” → “8”

The security rationale is not a formal generative probability model, but the combination of on-demand semantic variety, randomized prompts, and session-specific hashing. Because the question set is not fixed or public, there is no static corpus analogous to classical distorted-text CAPTCHA templates. Hashing prevents the client from seeing the correct answer directly, while per-session variation limits replay value (Nia, 29 Sep 2025).

On the client side, the browser renders the question, exposes an input field, attaches a keydown listener timestamped via performance.now() and a paste listener, computes local behavioral features, and submits those features together with the answer. The challenge generator and verifier are thus split cleanly: semantic generation remains server-side, while high-resolution input capture remains local.

3. Keystroke dynamics and the decision rule

The keystroke component is intentionally minimal and uses only press timestamps, not key release times, dwell times, or actual key identities. If the press times are

$T = \{t_1, t_2, \dots, t_n\},$

then the inter-key flight times are

$F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$

From these, CAPTCHA-X derives:

$T_{\text{total}} = t_n - t_1,$

$\mu_F = \frac{1}{n-1}\sum_{i=1}^{n-1} F_i,$

$$\sigma_F = \sqrt{\frac{1}{n-2}\sum_{i=1}^{n-1}(F_i-\mu_F)^2}.$$

The design premise is that human typing is naturally irregular, whereas scripted input often exhibits near-periodic timing or unrealistically low total duration (Nia, 29 Sep 2025).

The prototype uses a hard-threshold, rule-based fusion rather than a probabilistic or learned classifier. Let $x_c$ denote answer correctness, $x_k$ the keystroke feature vector $(T_{\text{total}}, \sigma_F, \mu_F)$, and $p$ the paste flag. A submission is classified as human iff all of the following hold:

1. the SHA-256 hash of the submitted answer matches the target hash;
2. $p = 0$;
3. $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$0;
4. $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$1.

The empirically chosen thresholds are:

• $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$2
• $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$3 for answers with more than 3 characters

This makes the current prototype a universal human-vs-bot discriminator rather than a per-user authentication system. The paper explicitly proposes replacing these heuristic thresholds with one-class SVM or autoencoder-based anomaly detection trained on larger human datasets, which would model a more nuanced “human region” in keystroke feature space (Nia, 29 Sep 2025).

4. Security properties and empirical evaluation

CAPTCHA-X is designed against bots that can submit HTTP requests, interact with form fields, paste answers, type answers programmatically with fixed delays, and even use LLMs or external knowledge services to solve the semantic question. Human-in-the-loop CAPTCHA farms are treated as out of scope in the strong sense, although the dual-layer design is intended to increase attacker cost by requiring both semantic solving and realistic typing behavior (Nia, 29 Sep 2025).

The cognitive layer mainly blocks generic scripts and reduces the value of replay, because questions are generated dynamically rather than drawn from a fixed bank. The behavioral layer blocks three explicit attack classes in the prototype:

• Paste-based attacks: any paste event causes immediate rejection.
• Scripted typing with fixed intervals: the evaluation bot used a fixed 50 ms inter-key delay, which yields $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$4 and fails the variance threshold.
• Extremely fast automated input: very low total duration fails the $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$5 threshold.

More adaptive bots with randomized delays are acknowledged as a limitation of the current rule-based detector; this is one reason the paper proposes richer feature sets and learned anomaly detectors as future work (Nia, 29 Sep 2025).

The proof-of-concept evaluation used 15 volunteers, each solving 3 challenges, yielding 45 human trials. Two bot types were tested for 50 trials each: a paste-based bot and a typing-simulation bot with fixed 50 ms per keystroke. The reported outcomes are summarized below.

Group	Trials	Outcome
Human users	45	100% success within two attempts
Paste-based bot	50	0% success
Typing-simulation bot	50	0% success

Human first-attempt success was 87%, with initial failures attributed mainly to typographical errors; success within two attempts reached 100%. The paste bot was always blocked by paste detection, and the typing-simulation bot always failed the $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$6 criterion. The paper does not report ROC curves, FPR, FNR, or a probabilistic fusion score, so the results should be interpreted as a feasibility demonstration against simple bot baselines rather than as an industrial-scale benchmark (Nia, 29 Sep 2025).

5. Usability, privacy, and limitations

Usability in the prototype is assessed mainly through completion outcomes and qualitative observation rather than standardized instruments. The questions are simple and intuitive, there is no need to decipher distorted text or noisy images, and keystroke capture is unobtrusive because users type naturally into a single answer field. The absence of a standardized SUS score or formal questionnaire means the usability evidence is limited, but the reported 87% first-attempt success and 100% success within two attempts indicate low cognitive burden under the tested conditions (Nia, 29 Sep 2025).

Privacy is a central design distinction. The prototype emphasizes one-shot, task-specific behavioral capture rather than cross-site profiling. It does not store key identities or long-term behavioral profiles, only timing-derived features for the challenge instance, and it presents itself as more transparent than systems such as reCAPTCHA v3 that rely on opaque, cross-site behavior tracking (Nia, 29 Sep 2025). At the same time, keystroke dynamics are still a form of behavioral biometrics, so real deployments would need explicit disclosure, retention limits, and compliance with data-protection regimes such as GDPR.

The limitations are substantial. The adversary model is simple, the bot baselines are basic, and the human sample is small and homogeneous. The thresholds $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$7 and $F_i = t_{i+1} - t_i, \quad i = 1, \dots, n-1.$8 were chosen empirically from pilot tests and may not generalize to very fast typists, users with motor impairments, mobile keyboards, or touchscreens. The feature set is narrow, using only inter-key latencies and two summary statistics. The design also depends on an external LLM API, introducing cost, latency, and rate-limit concerns. No specific accessibility evaluation is reported, despite the obvious relevance of typing variability to users with tremors, motor impairments, or non-standard input devices (Nia, 29 Sep 2025).

These concerns are consistent with broader user studies showing that CAPTCHA friction is often magnified on mobile devices, that accessibility fallbacks are unreliable, and that technically literate users are skeptical of both security and usability claims in existing systems (Reddy et al., 2024). CAPTCHA-X reduces some sources of friction, but it does not remove the need for rigorous accessibility testing.

6. Position within CAPTCHA research

CAPTCHA-X sits at the intersection of two research lines that were mostly separate in earlier CAPTCHA work. One line emphasizes cognitive challenges: question-based CAPTCHAs built from mathematical, logical, or general-knowledge prompts. Earlier frameworks in this tradition used predefined question banks and category-based selection, showing that natural-language question answering could be more usable than distorted text for many users (Chowdhury et al., 2013). CAPTCHA-X extends that line by replacing static question repositories with LLM-generated prompts and server-side answer hashing (Nia, 29 Sep 2025).

The second line emphasizes behavioral signals. Large-scale studies of deployed CAPTCHA ecosystems show that mainstream providers are vulnerable not only to automated solvers but also to low-cost human-solving services, and explicitly argue for new CAPTCHAs based on hard AI problems and behavior analysis (Jin et al., 2023). Related work on mouse trajectories goes further by reframing CAPTCHA-farm detection as identity inconsistency detection, using a single global model to compare CAPTCHA-time and session-time mouse behavior (Jin et al., 2023). CAPTCHA-X does not perform identity binding in that sense, but it adopts the same broader move: supplement explicit challenge solving with short-horizon behavioral biometrics.

Within the broader evolution of CAPTCHA design, CAPTCHA-X also differs from newer interactive defenses aimed at GUI agents. Recent next-generation CAPTCHA frameworks target the human–agent “cognitive gap” in interactive perception, memory, decision-making, and action through procedurally generated GUI tasks, motion cues, and drag-based manipulation rather than semantic text entry (Liu et al., 9 Feb 2026). CAPTCHA-X is therefore best understood as a compact, form-field-compatible hybrid: less ambitious than full interactive GUI-agent defenses, but more behaviorally grounded than classical text or image CAPTCHAs.

In that sense, CAPTCHA-X marks a transitional design. It retains the lightweight deployment model of a conventional web form, but shifts verification from a single perceptual puzzle to a fusion of dynamic semantic challenge generation and local behavioral analysis. Its prototype results establish feasibility, while its own future-work agenda—learned anomaly detection, richer biometrics, and mobile adaptation—indicates that the current system is a proof of concept rather than a finished CAPTCHA architecture (Nia, 29 Sep 2025).