---
title: 'CAPTCHA-X: LLM & Keystroke Dynamics'
url: https://www.emergentmind.com/topics/captcha-x
type: topic
---

# CAPTCHA-X: LLM & Keystroke Dynamics

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 [2510.02374].

## 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 [2306.07543].

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 [2510.02374].

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 [2405.18547]. 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 [2510.02374].

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 [2510.02374].

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 [2510.02374].

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. \(\sigma_F > \theta_\sigma\);
4. \(T_{\text{total}} > \theta_t\).

The empirically chosen thresholds are:

- \(\theta_\sigma = 20\text{ ms}\)
- \(\theta_t = 150\text{ ms}\) 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 [2510.02374].

## 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 [2510.02374].

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 \(\sigma_F \approx 0\) and fails the variance threshold.
- **Extremely fast automated input**: very low total duration fails the \(T_{\text{total}}\) 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 [2510.02374].

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 \(\sigma_F > \theta_\sigma\) 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 [2510.02374].

## 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 [2510.02374].

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 [2510.02374]. 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 \(\theta_\sigma\) and \(\theta_t\) 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 [2510.02374].

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 [2405.18547]. 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 [1312.7444]. CAPTCHA-X extends that line by replacing static question repositories with **LLM-generated** prompts and server-side answer hashing [2510.02374].

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** [2306.07543]. 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 [2312.10273]. 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 [2602.09012]. 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 [2510.02374].

Source: https://www.emergentmind.com/topics/captcha-x