Password-space combinatorics and cracking time
◈ 9 cardsCounting the passwords a composition rule actually admits — by inclusion–exclusion, not by a naive product — and turning the count into a defensible search time.
The question, set up precisely
A site requires passwords of exactly 10 characters, drawn from four classes:
- 26 lowercase letters,
- 26 uppercase letters,
- 10 digits,
- 32 special characters — the printable ASCII punctuation, which is four separate ranges: codes 33–47 (15 characters), 58–64 (7), 91–96 (6) and 123–126 (4). Add them: .
The alphabet is therefore characters. The rule also requires at least one character from each of the four classes. How many passwords satisfy it?
Why is the wrong answer
counts every string of ten characters over the alphabet. It is the count with no composition requirement, and it includes strings the rule forbids — aaaaaaaaaa, PASSWORD12, anything with no special character at all. A requirement removes strings; it never adds any. So the answer must be smaller than , and any method that produces a bigger number has the logic inverted.
The other tempting move is worse because it looks like counting. "Pin one position for each required class, then fill the rest freely": , or the sloppier . Both overcount massively, because a password containing three digits is produced many times over — once for each choice of which digit was 'the' required one. Choosing positions and then filling them freely double-counts, and there is no clean way to divide the duplication out.
Inclusion–exclusion, worked
Count the complement instead. Let be the set of length-10 strings containing no lowercase letter, no uppercase, no digit, no special. A string is bad exactly when it lies in at least one ; every other string satisfies the rule. Inclusion–exclusion gives the good count directly as an alternating sum over which classes are omitted:
where is the size of class . There are subsets. Read the sum term by term:
- — one term, : every string.
- — four terms, subtracted. Drop lowercase and characters remain, so ; drop uppercase, ; drop digits, ; drop specials, .
- — six terms, added back, because a string missing both lowercase and digits was subtracted twice above. Example: .
- — four terms, subtracted again. Example, keeping only the specials: .
- — one term, : no characters left, no strings.
Running the sum gives
against . The composition rule admits 60.03% of the unrestricted space — a reassuring sanity check, since the answer is smaller than but the same order of magnitude. If your inclusion–exclusion produces a ratio outside roughly 0.5 to 0.7 here, you have dropped a term or flipped a sign.
Notice what the rule cost the defender. Insisting on all four classes threw away 40% of the space — while, in exchange, removing the all-lowercase passwords that attackers try first. That trade is the honest argument for composition rules, and it is a much weaker argument than most policies assume.
From a count to a time
A count is not an answer to "how long would this take?" until you state a rate. That is the marked step, and leaving it implicit is the commonest way to lose marks on this question.
At guesses per second — a defensible figure for one well-equipped attacker with GPU hardware:
A year is seconds, so that is about 1,025 years. Raise the rate a thousandfold to guesses per second — a serious distributed effort — and the same space falls in about 1.03 years. Drop it to and it is over a million years. Three orders of magnitude in the rate move the answer by three orders of magnitude in the time, which is why the rate must be stated rather than assumed.
Two honest qualifications belong in any full answer.
First, the figure is the time for an exhaustive search of the whole space, so on average you succeed in half of it. Second, and far more important: no real attacker searches uniformly. Human password choice is enormously skewed, and modern cracking orders its candidates by that skew, using Markov models and probabilistic context-free grammars trained on leaked password corpora. Measured against a policy of exactly this kind, over 10% of real passwords fell within guesses and nearly 40% within — numbers that bear no relation at all to . The combinatorial count is an upper bound on the work, and effective entropy in practice runs under about 10 bits online and around 20 bits offline.
There is a companion trap worth naming, because it turns the whole calculation into theatre. If passwords are generated by a program whose pseudorandom generator is seeded from a 15-bit value, then no matter how large the nominal password space is, there are only distinct passwords the program can ever emit. The search space is the seed space. Counting the alphabet in that situation answers a question nobody asked.