What counts as a "keyboard walk"?

A sequence of characters that are physically adjacent to each other on a standard QWERTY keyboard -- like "qwerty", "asdfgh", "1qaz", or "zxcvbn" -- typed in order along a row, or in reverse. These feel random to type quickly but follow a completely predictable physical pattern rather than being genuinely random.

Why are keyboard walks considered weak?

Password-cracking wordlists and tools check for keyboard walks specifically, right alongside dictionary words and common passwords -- because they're an extremely common shortcut people take when asked to create a password quickly. A pattern that's easy for a human to type from muscle memory is just as easy for an attacker's tool to guess.

Does this only check horizontal rows?

Yes -- this tool checks the four standard QWERTY rows (number row, top letter row, home row, bottom row) in both forward and reverse order. It doesn't currently check diagonal or vertical adjacency (like "1qaz2wsx"), which is a narrower and less commonly exploited pattern.

I found a keyboard walk in my password -- what should I do?

Replace that segment with something unrelated to key position -- ideally switch to a passphrase built from random unrelated words (see this site's Passphrase Generator), or a fully random password from the Password Generator, rather than trying to patch just the flagged section.

Is my password sent anywhere?

No. The entire check runs locally in your browser using this site's own pattern data -- nothing is transmitted to a server or stored.

Detect Keyboard Walks in a Password — Free Pattern Checker

Drop a password into the Keyboard Walk Detector and it scans it for keyboard-walk patterns — sequences like qwerty, asdf, or 1qaz that trace adjacent keys on a standard layout. Every match gets highlighted directly in your password, so you can see exactly which part of it an attacker's cracking tool would spot first, since these patterns are among the very first ones tried.

Ever wondered whether a credential like qwerty or 123456 is genuinely secure — or just a keyboard sequence waiting to be cracked? A keyboard walk detector analyzes any input string and tells you whether it follows a predictable physical path across the keys, giving you actionable intelligence about real credential vulnerability before attackers exploit it. Whether you're enforcing password rules, conducting a security audit, or researching breached credential data at scale, understanding what the detector finds — and why — is the difference between credential security and credential exposure.

How a Keyboard Walk Detector Protects Your Security Policy

A keyboard walk is any sequence of characters that traces a recognizable physical path on a key arrangement. Think of running your fingers diagonally from top-left to bottom-right, or sweeping horizontally across a row. These sequential key runs are among the most used sequential patterns found in breached credential data. Statistical analysis of large data dumps — some containing over 800 million entries — consistently show that common runs like qwerty, asdfgh, and zxcvbn appear in hundreds of millions of accounts. They're predictable not because users are careless, but because the physical arrangement of keys makes them feel natural and memorable.

The problem is equally well understood from the attacker's perspective. Credential cracking tools and dictionary attack wordlists almost universally include every common sequential key run as a top-priority guess. Brute force campaigns often prioritize these runs because they reduce the effective search space dramatically. Shoulder surfing — the low-tech attack of simply watching someone type — becomes trivially effective when a credential is a straight horizontal sweep across the keys. The keyboard pattern rule in modern security enforcement exists precisely because these patterns represent a known, measurable vulnerability, not a theoretical one.

A keyboard walk detector applies a walk detection routine to each submitted string, traversing the input character by character and checking each successive keystroke against a key adjacency map. The tool flags or scores the entry based on whether it finds a valid traversal — a consistent path across the key graph that meets or exceeds a configurable run length threshold. This is fundamentally a graph theory and pattern recognition problem: the keyboard is modeled as a graph data structure, where each key is a node and the edges connecting nodes carry directional information representing key neighbor relationships. Graph traversal of the input string then determines whether any substring constitutes a keyboard sequence long enough to trigger rejection under the active password rules.

How Direction Change Detection Flags Sequential Key Runs

The most basic sequential run is a pure linear path with no direction change — the user presses keys moving consistently in one edge direction from start to finish. However, many real-world patterns involve a turn. The sequence qwewq, for example, traces forward along the top row then reverses — a V-shape rather than a straight line. Direction change detection extends the tool's coverage to these cases. When detect direction change is enabled, the walk detection routine tracks the current traversal direction at each step and counts a change of direction as either permitted (within tolerance) or as a signal to flag the pattern.

In terms of the key graph, a direction change occurs when the edge direction from key n to key n+1 is the opposite of — or significantly different from — the direction from key n-1 to key n. The tool maintains a direction interface that records the current vector and compares it against the next step. Shapes like a V shape or an X shape in the key path are captured this way. With direction change detection enabled and the scan mode set to cover both axes, sequences such as qawsed, qwedsa, qwedcv, and qwsazx are all recognized as six-character sequential patterns. This is a critical extension: without it, a credential that uses the same keys but doubles back would escape detection by simple linear-run checks.

From an implementation standpoint, each RunKey object stores not just its key neighbor references but also the directional relationship to each neighbor. When the routine processes a key sequence, it resolves a direction for each transition and compares successive directions. A consistent direction produces a valid traversal; a reversal triggers the direction change counter. If the number of direction changes exceeds the tolerance value, the pattern is flagged. The programming community — particularly Python — has explored this extensively, with graph libraries providing nodes, edges, and graph structure primitives that make key modeling straightforward, including backtracking to re-evaluate ambiguous path segments.

Detecting Key Repeats and Skipped Keys in Sequential Patterns

Two additional checks extend the reach of sequential pattern detection beyond simple sequential runs: key repeat detection and key skip detection. These address real-world evasion patterns where users attempt to disguise a sequential run with repeated keystrokes or by skipping a key in the sequence.

Key repeat detection (detect key repeat) catches patterns like qwwert and qwwwer, where the same key appears consecutively within what is otherwise a linear run. Without this check, a security enforcer would miss these as sequential patterns because a repeated keystroke breaks the strict adjacency requirement. With this check enabled, the routine identifies repeated keystrokes as a permitted deviation from strict adjacency — the run length counter continues, and the sequence is still recognized as a pattern. For example, both qwwert and qwwwer are recognized as six-character patterns when this option is active.

Key skip detection (detect key skip) handles a different evasion: the horizontally skipped key. In the sequence qwryui, the character e is missing between r and y — the user's finger moved one key further than a strict adjacency would allow. This check permits a skipped key as a valid step in the path, recognizing that the overall trajectory is still a sequential run. With this option enabled, qwryui is flagged as a six-character pattern. The concept generalizes: any time the distance between two consecutive input keys is two positions rather than one along the row — a skipped key — the tool can either flag it (strict mode) or absorb it as a permitted deviation.

Together, these three checks — direction change detection, key repeat detection, and skipped-key identification — give the tool configurable coverage of the full space of sequential key run variants. The tolerance parameter ties them together: it specifies the longest pattern the credential tolerates before rejection. A tolerance value of three means any four-character sequential pattern or longer triggers rejection; a tolerance of five allows patterns up to five characters. This lets you calibrate the rule to your specific complexity requirements without false-positiving on credentials that happen to contain short common substrings. Strength enforcement depends on choosing the right tolerance for your environment.

Recognizing Breached Credentials Through Common Sequential Runs

The following are among the most used sequential key runs found in real breached credential data. Intelligence research and statistical analysis of data dumps repeatedly surface these same runs. Recognizing them is the first step to rejecting them at the point of entry:

123456
654321
qwerty
121212
987654
456789
asdfgh
232323
212121
zxcvbn
098765
1q2w3e
234567
090909
454545
898989
565656
redred
qwaszx
567890
lololo
909090
4esz
4rfc
qwer

Each of these represents a distinct sequential run type. qwerty is a pure horizontal sweep across the top letter row. zxcvbn traces the bottom letter row left to right. asdfgh runs the home row. 1q2w3e is a diagonal alternating pattern between the number row and the top letter row — a classic example of a credential that looks complex but traces a perfectly consistent path across both axes. 4esz and 4rfc illustrate vertical scanning: these sequences move down through rows rather than across them. The entry qwer represents the minimum-length four-character run that many policies target as a threshold, and it is a classic password subset of longer horizontal runs.

Graph Structure and the Walk Detection Routine

Under the hood, the keyboard walk detector is an application of graph theory to credential analysis. The key arrangement is represented as a graph data structure: each physical key becomes a node, and directed edges connect each key to its adjacent keys in every possible direction — left, right, top-left, top, top-right, bottom-left, bottom, bottom-right. This produces a rich adjacency map that captures the physical geometry of the standard US key arrangement, including the staggered offset between rows that makes diagonal paths like 4esz physically intuitive to type.

Each node stores references to its neighbors by direction. A minimal implementation of this concept uses a RunKey lookup class — a proof of concept (POC) structure where each character maps to a key object that exposes its directional neighbors:

a = RunKey.get("A");

public class RunKey {
    public static Key get(Character c) {
        switch (c) {
            case 'A': case 'a': return new A();
            // one case for every key on the arrangement
        }
    }
}

private class A extends RunKey implements IRunKey {
    public IRunKey BR() { return new Z(); }  // Bottom-Right neighbor
    public IRunKey TR() { return new W(); }  // Top-Right neighbor
    public IRunKey T()  { return new Q(); }  // Top neighbor

    public Direction getDirection(char c) {
        IRunKey tempRunKey = RunKey.get(c);
        if (tempRunKey.T().toString().equals(String.valueOf(c))) {
            return Direction.T;
        }
        // ... other direction checks
    }
}

Here, the A key object knows that its top-right neighbor (TR) is W, its top neighbor (T) is Q, and its bottom-right neighbor (BR) is Z. The getDirection method resolves which direction a given character sits relative to the current key — the core of the key neighbor traversal logic. A direction interface standardizes the return type so the walk detection function can compare successive directions numerically or symbolically.

The walk detection function works as follows. It iterates through the input string, resolving a RunKey object for each character. For each pair of consecutive characters, it calls getDirection to determine the edge direction between them. If the direction is consistent with the previous step (or falls within the tolerance for direction changes, key repeats, or skipped key positions), the run length counter increments. If the transition is inconsistent and the deviation count exceeds tolerance, the current run ends and a new one begins — using backtracking where necessary to confirm the longest valid path. At the end of input traversal, the tool reports the longest sequential pattern found. If that run length exceeds the configured tolerance value, the entry is flagged.

In more complete implementations — such as those built with Python graphs or similar graph libraries — each node carries both its unshifted character and its shifted version (e.g., 1 and !, or a and A). The walk detection routine can traverse edges between a key and its shifted version, meaning that a sequence like 6yhn^YHN — which mixes unshifted and shifted keys while tracing the same physical path — is still detectable as a sequential run. Modifier keys such as the shift key and AltGr do not evade detection in a correctly implemented tool, because the adjacency map includes edges to shifted versions of each key. Note that key positions can differ across physical keyboards even when the arrangement name matches, so some patterns may go undetected on non-standard hardware.

Worked Example: Detecting Credential Strength Failures Step by Step

The following three examples walk through how the tool processes real inputs, demonstrating each of the primary detection modes and how the tolerance setting affects the outcome.

Example 1 — Pure horizontal run: qwerty

Initialize: The tool loads qwerty as a six-character input string. Run length counter = 1, direction = undefined, deviation count = 0.
Step q → w: RunKey for q resolves its right neighbor as w. Direction = Right. Run length = 2.
Step w → e: Right neighbor of w is e. Direction = Right (consistent). Run length = 3.
Step e → r: Right neighbor of e is r. Direction = Right (consistent). Run length = 4.
Step r → t: Right neighbor of r is t. Direction = Right (consistent). Run length = 5.
Step t → y: Right neighbor of t is y. Direction = Right (consistent). Run length = 6.
Result: Longest sequential pattern = 6 characters, horizontal sweep, no direction change, no skipped keys, no repeated keystrokes. With a tolerance of 3 or lower, this entry is rejected. This is a textbook horizontal run — the path covers the entire input.

Example 2 — Numeric run with direction change: 123454321

Initialize: Input is nine characters. Run length = 1, direction = undefined.
Steps 1 → 2 → 3 → 4 → 5: Each step moves Right along the numeric row. Direction = Right consistently. Run length reaches 5.
Step 5 → 4: The right neighbor of 5 is 6, but the input shows 4 — which is the left neighbor. Direction reversal detected. If detect direction change is disabled, the run ends here (length 5). If enabled, the direction change is recorded and the run continues.
Steps 4 → 3 → 2 → 1 (with direction change enabled): Continued traversal in the Left direction. Run length reaches 9, covering the full n characters of input.
Result: With direction change detection enabled, the full sequence is recognized as a nine-character sequential path (a V shape on the numeric row). With it disabled, two separate runs of length 5 and 4 are reported. Either way, the entry fails a tolerance setting of 3 or lower.

Example 3 — Diagonal run with skipped keys: 1q2w3e

Initialize: Input alternates between the number row and the top letter row. This is a known complex sequential path.
Step 1 → q: q is the bottom neighbor of 1 on the standard US arrangement. Direction = Bottom. Run length = 2.
Step q → 2: 2 is the top-right neighbor of q. Direction changes to Top-Right. If detect direction change is enabled and the deviation count is within tolerance, the run continues. Run length = 3.
Steps 2 → w → 3 → e: The pattern repeats the same alternating vertical-then-diagonal traversal. Each transition matches the known path for this diagonal run.
Result: The full six-character sequence is recognized as a diagonal sequential path demonstrating key traversal across rows. The entry is flagged if the tolerance is set to five or lower. This example illustrates how skip tolerance and direction change detection together handle non-adjacent-row patterns that naive horizontal or vertical checks would miss.

These examples make clear why a keyboard walk detector cannot be replaced by regular expressions. A regex alternative could match a hard-coded list of known patterns, but it cannot generalize to the combinatorial space of all possible n-combinations of key paths — including complex runs, shapes like a V shape or X shape, or novel diagonal patterns not yet in any wordlist. Programmatic detection via graph traversal is the only scalable approach, and it is why programming the solution properly with graph theory yields far better coverage than static rule lists.

Configuring the Keyboard Walk Detector for Strength Enforcement

Deploying this tool in a real authentication or security enforcement context requires configuring four key parameters: the scan mode (horizontal, vertical, or both axes), the three deviation checkboxes (detect direction change, detect key repeat, detect key skip), the tolerance dropdown list value, and the selection of active key arrangements to scan against.

The enabled checkbox activates the sequential pattern rule. The dropdown list for scan mode controls which axes are scanned: horizontal covers runs like qwerty and sequential bottom-row runs; vertical covers runs like 4esz and similar column-wise paths; and scanning both axes simultaneously is the most comprehensive setting for strength enforcement in high-security environments.

The tolerance is the single most impactful setting for balancing security against usability. A four-character threshold rejects any entry that contains qwer or longer as a substring. A five-character threshold permits four-character runs but rejects five or more. A six-character threshold is more permissive still. Most security frameworks targeting Active Directory (AD) environments or comparable enterprise contexts recommend a tolerance no higher than three, ensuring that even short sequential runs are rejected at the point of entry.

The key arrangements button allows you to select which layouts the client scans against. You must select at least one — the standard US arrangement is the default — but multiple variants can be enabled simultaneously. This matters for international deployments: a pattern that is not a run on a US arrangement might be a perfectly linear path on a different regional variant. The sequential pattern rule may not detect all patterns due to physical key position differences across hardware, so enabling multiple variants expands coverage. Modifier keys such as shift key and AltGr are handled by the adjacency map and do not allow a user to evade detection by capitalizing part of a run.

The Messages tab in the client interface allows customization of the rule inserts — the user-facing text displayed when an entry is rejected for containing a sequential pattern. Clear feedback improves compliance rates by telling users exactly what was wrong, rather than leaving them to guess why their entry was rejected.

Reminder: Upvoting community answers and keeping the enabled checkbox active for all three detection options (detect direction change, detect key repeat, detect key skip) gives you the most comprehensive coverage against sequential pattern evasion. For maximum security, pair the sequential pattern rule with entropy checks, dictionary attack filtering, and a breached credential data feed to cover all major credential security threat vectors.

From a cybersecurity and cryptography standpoint, the value of the keyboard walk detector is that it targets a specific, measurable reduction in credential entropy — a core goal of strength enforcement. A six-character entry chosen uniformly at random has vastly more entropy than one constrained to follow a key path — but a sequential run of the same length has entropy close to zero, because an attacker who knows the key arrangement can enumerate every possible run in seconds. Analysis of data breach collections confirms this: sequential key runs are not edge cases but a dominant category in exposed credential data, accounting for a disproportionate share of cracked entries. This tool gives any security policy, access control system, or credential intelligence platform a direct, graph-theoretic means for eliminating this vulnerability class at the point of creation, rather than discovering it after a breach.

Frequently Asked Questions

What counts as a "keyboard walk"?: A sequence of characters that are physically adjacent to each other on a standard QWERTY keyboard -- like "qwerty", "asdfgh", "1qaz", or "zxcvbn" -- typed in order along a row, or in reverse. These feel random to type quickly but follow a completely predictable physical pattern rather than being genuinely random.
Why are keyboard walks considered weak?: Password-cracking wordlists and tools check for keyboard walks specifically, right alongside dictionary words and common passwords -- because they're an extremely common shortcut people take when asked to create a password quickly. A pattern that's easy for a human to type from muscle memory is just as easy for an attacker's tool to guess.
Does this only check horizontal rows?: Yes -- this tool checks the four standard QWERTY rows (number row, top letter row, home row, bottom row) in both forward and reverse order. It doesn't currently check diagonal or vertical adjacency (like "1qaz2wsx"), which is a narrower and less commonly exploited pattern.
I found a keyboard walk in my password -- what should I do?: Replace that segment with something unrelated to key position -- ideally switch to a passphrase built from random unrelated words (see this site's Passphrase Generator), or a fully random password from the Password Generator, rather than trying to patch just the flagged section.
Is my password sent anywhere?: No. The entire check runs locally in your browser using this site's own pattern data -- nothing is transmitted to a server or stored.