Text & everyday tools · Password Generator
Dictionary attacks: from the 1988 Morris worm to leaked password lists
· Background
passwords dictionary-attacks passphrases
Explains how dictionary attacks evolved — from a worm carrying a small word list to modern cracking with leaked-password corpora and mangling rules — and why a random passphrase from a public list is not a dictionary word in the sense that matters.
A worm with a word list — how the 1988 Morris worm guessed passwords with a built-in dictionary and the system word file
The workbook opens with details about the Morris worm and built-in word files, but the Password Generator repository is not a historical source for that event. No primary code, paper or archive is cited here. Repeating the story would violate the requirement not to quote security history from memory.
The product-relevant question can be answered without that narrative: does using words from a public list make a uniformly generated phrase equivalent to one dictionary word? No. The engine selects an ordered sequence of independent indices, and the number of combinations follows from the verified pool and draw count.
The Morris-worm history is outside the repository’s evidence
Conceptually, a dictionary attack tries candidates believed more likely than a uniform sweep. Human-created words, names and phrases can enter that ordering early. This article assigns no throughput, success rate or dictionary size because the repository supplies no attacker dataset or tool configuration.
ToolAcre does not model that ordering. It avoids the human-choice problem by drawing from a known pool with Web Crypto. The result still needs to remain private and unique; random selection does not protect a phrase copied from documentation or reused after exposure.
A dictionary attack is discussed only as a threat-model boundary, without statistics
Leaked password corpora are external, changing datasets. Their sizes, contents and influence on cracking tools cannot be established from the local generator code. This section therefore omits breach statistics and named corpora rather than freezing an unsupported claim into evergreen content.
The omission does not weaken the recommendation against reuse. ToolAcre’s limitations explicitly name reuse as a separate failure mode. A fresh credential per account limits the consequence of one service exposing a value, regardless of how an attacker prioritizes candidates.
Leaked-password corpora require external evidence and are omitted
Capitalizing the first letter, appending a year or substituting a symbol may follow predictable human rules, but this repository contains no measured claim about how often an attacker applies each one. ToolAcre’s fixed case modes are therefore counted as deterministic formatting, not extra entropy.
When composition is required, the character generator makes random class choices and shuffles positions. That is a documented process. Hand-editing a generated phrase with a personal suffix creates a different process and invalidates the previous estimate.
Mangling-rule examples are not treated as measured attack behavior here
A public long list still offers 7,776 possible indices for each unfiltered draw. Four independent ordered selections therefore produce 7,776⁴ combinations. The attacker may know the list and settings; the selected sequence remains unknown unless it has been exposed or reused.
Filtering changes the base, and acrostic mode constrains selection by initial letters, so calculations must follow actual settings. Public vocabulary is not permission to hide these constraints. The engine derives from the eligible pool and reports its assumptions.
Why uniform combinations remain countable even when the source list is public
For a generated four-word long-list phrase, derive 7,776⁴ directly from the tested file size and four independent positions. Do not print a sample phrase as a candidate. For a person-chosen four-word expression, leave the count unknown because no probability model for the person’s choices is supplied.
This comparison avoids crack-time estimates and does not say four words are sufficient for every use. It illustrates why process evidence matters. A known count can inform settings, while suitability still depends on the destination and threat model.
Worked example: derive the generated combination count and leave human choices unquantified
Rainbow tables, GPU performance and hash-specific optimization require information about the stored verifier and attack platform. They are outside this generator and omitted. ToolAcre has no server-side password database whose configuration could ground those topics.
Adding hardware claims would also tempt the article into unstable figures. The durable local facts are uniform choice counts and product boundaries. External attack engineering belongs in a separately sourced analysis.
The takeaway — the words in the Password Generator's output are in a public dictionary, and that is fine; the random combination is what attackers cannot enumerate cheaply
The EFF words can be public because secrecy comes from the fresh random ordered combination, not from hiding vocabulary. ToolAcre draws indices without modulo bias and never stores a history. The user must keep the resulting sequence private and unique.
Do not turn public-word arithmetic into a promise against every attacker. The generator does not prevent phishing, malware, reuse or poor remote storage. It gives a countable selection process; responsible handling and system controls must carry the result from there.