English

Text & everyday tools · Password Generator

Bits of entropy vs strength meters: what the number really measures

· Background

passwords entropy strength-meters

A transparent choice-count calculation beside an opaque colored meter
Original ToolAcre vector illustration

Explains what a bit of entropy is, why it can be calculated exactly for generated passwords but only estimated for human-chosen ones, and why strength meters and entropy figures often disagree.

The green bar that lied — a strength meter loves 'P@ssw0rd2024' and shrugs at a six-word passphrase

ToolAcre does not show a colored red-to-green bar or accept a password for grading. It estimates the random process configured in its own generator and states assumptions beside the result. The workbook’s claim that a typical meter loves one example and rejects another requires evidence from a named implementation, which is not part of this repository.

Correcting that heading matters because a transparent calculation and a heuristic score answer different questions. ToolAcre knows its pool, draw count, case rule and delimiter rule. It does not know how a string chosen elsewhere was produced, so it refuses to imply that appearance alone reveals strength.

A green strength bar is outside this tool; ToolAcre reports a stated generator estimate

One bit represents a doubling in the number of equally possible outcomes. If a draw has N uniform options, its contribution is log₂(N). Independent choices add. This arithmetic is exact for the stated model, but the repository supplies no universal bit threshold that makes a password appropriate for every account.

Threat models differ, and generated values remain vulnerable to compromise paths that do not enumerate the space. A count can compare settings while still saying nothing definitive about phishing, malware, reuse, recovery or a destination that stores credentials badly.

A bit calculation follows verified choice counts, without a universal safety threshold

The same visible word sequence can result from secure random indices or from a person selecting a quotation. The strings match while the processes differ. ToolAcre estimates the first because every random operation is known; it does not estimate the second because human preferences and attacker ordering are not modeled.

This process-first view also explains why deterministic formatting adds no entropy. Fixed capitalization and separators transform the selected words predictably. Random case and random delimiters add explicit choices because the engine performs fresh draws for them.

The estimate describes the generation process and settings, not the visible string alone

For generated values, the package can calculate from the actual filtered wordlist and the configured draws. Character mode uses its selected alphabet size and requested length. These inputs are visible and testable, allowing the estimate to change when a user narrows the pool or disables a class.

Human-created values need a model of likely choices, not merely an alphabet raised to a string length. ToolAcre does not contain that model and does not invite users to paste existing credentials, which also avoids exposing a secret for a dubious score.

How strength meters work — rule counting, dictionary checks and pattern matching, and where each misleads

Some external meters use dictionaries, pattern matching or composition heuristics, but their rules and versions are not source material here. This article therefore does not stage a fake contest against a “typical” meter. A valid comparison would need a named implementation, inputs and current code.

The absence is deliberate. Heuristic behavior can change independently of ToolAcre, while the generator estimate remains tied to repository-controlled operations. Readers should interpret another meter from its own documentation rather than assume every green bar means the same thing.

Third-party strength-meter behavior is outside repository evidence

Start with six words from an eligible pool of N under fixed lowercase and spaces: the word contribution is 6 × log₂(N). Switch to random case and add six binary choices. Switch back to fixed case and add a seventh word; the increment is log₂(N). Each difference follows one visible setting.

For character mode, use the exact selected alphabet reported by the source and multiply log₂ of its size by length as the package’s estimate does. These calculations compare supported processes. They do not produce a credential example, crack-time forecast or universal recommendation.

Worked example: calculate three supported setting changes without simulating a meter

Shannon entropy of natural-language corpora and research guessing metrics are outside the generator implementation. So are empirically trained password models. Conflating them with a uniform-choice calculation would make one familiar word “entropy” cover several incompatible definitions.

The product’s limitations page already takes the safer route: the number describes settings under stated assumptions, and time estimates are comparisons rather than predictions. Keep those qualifiers attached whenever the number is quoted.

The takeaway — a generated passphrase has a known entropy, which is why the Password Generator can be honest about strength

A generated passphrase has a calculable model because ToolAcre controls and exposes the random choices. That transparency is the useful property. The resulting bit figure is not intrinsic paint on the characters and does not guarantee safety across every attacker or system.

Use the estimate to audit configuration changes, then keep the actual value private and unique. Do not use ToolAcre as a manager or paste an existing credential for evaluation. A clear model is better than a confident meter only when its boundary remains visible.