How Keystroke Dynamics Actually Detect Bots (No PII Required)

"Keystroke dynamics" sounds like it should mean something biometric and identity-related — like a fingerprint made of typing. In a bot-detection context, that's the wrong mental model, and it's worth being precise about the difference.

The goal isn't to identify who is typing. It's to answer a narrower question: does this typing pattern look like it came from a human hand, or from a script?

What actually gets measured

A keyboard event stream gives you, at minimum, a keydown and keyup timestamp for every key. From that alone you can derive several feature families:

• Dwell time — how long a key stays pressed (keyup - keydown for the same key). Human dwell time has natural variance; naive scripted input either has near-zero dwell time or a suspiciously fixed constant.
• Flight time — the gap between releasing one key and pressing the next. This is where typing rhythm lives, and it's strongly influenced by finger biomechanics that are hard to synthesize from first principles.
• Digraph and trigraph latencies — timing for specific two- and three-key sequences (e.g., "th", "ing"). Humans are measurably faster on common sequences they've typed thousands of times, which produces a rhythm fingerprint that's statistically distinctive even without identifying a person.
• Error and correction patterns — backspace frequency, pause-before-correction timing, and hesitation before longer or rarer words.

None of these features require storing what was typed. A well-designed pipeline extracts timing statistics and discards the actual keystrokes immediately — the model never needs to know the content, only the rhythm. That's what makes this PII-free by construction rather than by policy.

Why naive automation fails this test

Most scripted form-filling uses one of a few patterns, and each leaves a distinct signature:

1. Instant value injection (element.value = "...") produces no keystroke events at all — an immediate red flag for any form expecting typed input.
2. Fixed-delay typing (sleep(50ms) between characters) produces dwell and flight times with near-zero variance — real human typing has variance on the order of tens of milliseconds even for the same person typing the same word twice.
3. Randomized-delay typing is a meaningful step up, but naive randomization (e.g., uniform random delay) doesn't reproduce the structure of human timing — the correlation between digraph frequency and speed, the fatigue-based slowdown over a long input, or the specific hesitation pattern before a decision point like an email field.

A model trained on real typing sessions learns this structure implicitly. It doesn't need a rule that says "flag uniform delays" — it learns the shape of the distribution well enough that scripted input falls outside it.

From raw events to a score

In practice, this looks like a small pipeline:

```text raw keydown/keyup events → feature extraction (dwell, flight, digraph stats) → normalization per session → sequence/embedding model → human-likelihood contribution to the overall trust score ```

Keystroke dynamics is rarely the only signal in production — it's one modality feeding a broader ensemble alongside mouse movement, touch, and navigation timing, because any single behavioral channel can, in principle, be targeted once an adversary knows it's being measured. Combining independent, cheap-to-compute signals is what makes the overall system meaningfully harder to game than any one of its parts.

Why this scales better than challenge-based detection

The practical advantage isn't just accuracy — it's cost and friction. Feature extraction from an event stream that's already flowing through the page is computationally cheap and invisible to the user. There's no puzzle to render, no round-trip to a challenge service, and no moment where a legitimate user is asked to prove anything. The verification happens as a side effect of the user simply doing what they came to do: type.