Brute Force Time Calculator
Estimate how many candidates exist in a uniformly generated secret, how long an exhaustive search could take at a stated guess rate, and how much of the space fits inside a chosen attack budget. The result separates an exact combination count from time-based estimates so very large spaces remain understandable.
Defensive use only. This planning model is for choosing stronger passwords, tokens, recovery codes, and rate limits. It does not test a live account, recover a credential, or authorize access to any system.
Search-space map
At one billion guesses per second, a uniformly random 12-character base-62 secret has an average exhaustive-search time measured in tens of thousands of years. This is a mathematical scenario, not a promise about a human-chosen password.
Read the result without overestimating security
Combinations are exact
The total candidate count is calculated as alphabet size raised to secret length. The calculator preserves this count as a whole-number string even when it is larger than ordinary JavaScript integer precision. It therefore provides a dependable view of the theoretical space for the entered model.
Time depends on rate
Worst-case time assumes the correct candidate is attempted last. Average time assumes no information favors one candidate and therefore uses half the space. Change the guess rate to test a particular defensive scenario; do not treat the default as a universal cracking benchmark.
Probability uses the budget
The success estimate divides the number of guesses available during the selected time budget by the total combinations, capped at 100 percent. It describes simple uniform enumeration with no repeated candidates, no lockouts, and no advantage from predictable choices.
A base-62, 12-symbol secret illustrates exponential growth. It has 62 choices at the first position, 62 at the second, and the same number at every remaining position. Multiplication across all positions produces 6212, or 3,226,266,762,397,899,821,056 candidates. Increasing length to 13 does not merely add 62 possibilities; it multiplies the entire prior space by 62. That distinction is why truly random length can be so powerful.
Alphabet size alone can mislead. A person told to use uppercase letters, lowercase letters, numbers, and symbols may still select a familiar phrase with a predictable capitalization pattern and a year on the end. Such a password is not sampled uniformly from the advertised alphabet. An attacker can prioritize common words and mutations instead of beginning with a blind, exhaustive enumeration. Use this calculator for secrets generated uniformly by a password manager or another trustworthy generator, or label the result as a theoretical upper-bound scenario.
Online guessing and offline guessing are different risk models
Controls can dominate the rate
An online attempt is sent to a live service. Rate limiting, progressive delays, device and network signals, account lockouts, bot detection, and phishing-resistant multifactor authentication can sharply limit useful attempts. The rate should reflect the whole service control, not the speed of a local processor.
For planning, enter a conservative attempt rate that your logs and controls support. Then test whether alerting would detect sustained attempts before the selected budget expires. A large theoretical password space is helpful, but it is not a replacement for protections around the authentication endpoint.
Hashing design can dominate the rate
An offline scenario may become possible if an attacker obtains stored password verifiers. No online lockout is involved. The relevant rate depends on the password hashing scheme, its cost settings, salts, available hardware, implementation, and the particular candidate strategy. A single generic guesses-per-second figure cannot represent every system.
Use a rate measured against the actual defensive configuration, then add slower and faster sensitivity cases. Modern, salted, deliberately expensive password hashing helps reduce the attempt rate. Incident response and credential reset planning still matter because even a well-designed verifier does not turn weak, reused, or exposed passwords into random secrets.
Choosing a defensible guess-rate input
The guess-rate field is a scenario input, not a fact supplied by the secret itself. Start with the system boundary. For an online service, use observed permitted attempts over time after all throttling and abuse controls. For an offline study, use authorized benchmark results for the exact verifier type and cost configuration. Preserve the date, test environment, assumptions, and hardware description alongside the result because a bare rate is difficult to audit later.
| Planning scenario | What the rate should represent | What to document |
|---|---|---|
| Consumer sign-in page | Successful processing of hostile attempts after throttling, not raw HTTP capacity. | Per-account limits, IP or device controls, delay schedule, MFA, and alert threshold. |
| Enterprise identity provider | The effective sustained rate across relevant identities under monitored controls. | Federation path, smart lockout behavior, risk engine, and escalation workflow. |
| Authorized offline audit | Measured candidates per second for the actual stored-verifier configuration. | Algorithm, work factor, salt behavior, hardware, software version, and test policy. |
| Random API token review | A hypothetical enumeration rate appropriate to the validation endpoint and token design. | Token alphabet, random source, expiration, scope, revocation, and request controls. |
Run multiple cases instead of chasing one impressive duration. A baseline, a ten-times-faster case, and a hundred-times-faster case reveal whether the design has meaningful margin. Because time is inversely proportional to rate, multiplying the rate by 100 divides both average and worst-case time by 100. The combination count and entropy do not change. This separation helps teams distinguish cryptographic space from operational defenses.
A practical security-review workflow
- Describe how the secret is generated. Record whether it comes from a uniform random generator, a password manager, a user choice, or a structured issuance system. Only the first two may reasonably match the uniform assumption without further analysis.
- Count the real alphabet. Include only symbols that can appear at every modeled position. If a token has a fixed prefix, checksum, separator, or version field, separate that structure instead of counting those characters as random.
- Enter the random length. Count independent unpredictable positions, not the total display length. A 20-character key containing eight fixed characters has 12 random positions for this simple model.
- Select an authorized rate. Prefer measured data from the actual defensive system. When measurements are unavailable, declare the rate as a sensitivity assumption and show more than one case.
- Choose a meaningful budget. An online detection window, credential rotation interval, token expiration, incident containment target, or equipment lifetime is more useful than an arbitrary duration.
- Review adjacent failure paths. Check recovery procedures, session security, reuse, phishing resistance, verifier storage, logging, and revocation. The brute-force result covers only one route.
Both tools use mathematical models, but the entropy page can help frame alphabet and length assumptions before a time scenario is built. Keep the full link with the review record so readers can reproduce the reasoning.
Worked example: a random base-62 identifier
Suppose an application issues an identifier with 12 independent characters selected uniformly from uppercase letters, lowercase letters, and digits. The alphabet size is 62 and the random length is 12. The exact search space is 6212, which equals 3,226,266,762,397,899,821,056. Its mathematical entropy is about 71.45 bits.
For an intentionally aggressive scenario of one billion distinct guesses per second, an exhaustive search would take about 102,234 years in the worst case. With the correct identifier uniformly located in the search order, the mean is half of that, about 51,117 years. During one day, the scenario allows 86.4 trillion guesses. Dividing those guesses by the full space gives a success chance of roughly 0.000002678 percent, or approximately one part in 37.3 million.
That result applies only if the identifier is actually secret, uniformly generated, independently sampled, and checked in a way that permits the stated rate. If identifiers are visible in URLs, logs, analytics, browser histories, support messages, or referrer data, enumeration may not be the main risk. If the validation endpoint leaks whether a prefix is correct, the attacker may not face the full space. The calculation is therefore one input to architecture review, not an approval decision.
Frequently asked questions
What does average brute-force time mean?
It is half of the full enumeration time under a uniform model. If the correct candidate is equally likely to appear anywhere in a nonrepeating search order, some searches finish early and some late; the mean location is near the midpoint. It is not a guaranteed deadline and does not describe smarter, nonuniform candidate strategies.
Should I include symbols in the alphabet size?
Include symbols only when the generator can choose them uniformly at every modeled position. Merely allowing symbols in a password policy does not make a human-selected password uniformly random. If a system requires one symbol in a fixed or predictable pattern, this simple alphabet-to-the-length model overstates the true generation process.
Why can an online attack be much slower?
A live service can restrict attempts through rate limits, progressive delays, risk signals, account protections, and multifactor authentication. Network round trips and monitoring also matter. Enter an effective rate supported by the service design and observed behavior, not a processor benchmark copied from an unrelated offline test.
Does a 100-year result mean the secret is safe for 100 years?
No. The duration covers only uniform brute-force enumeration at the entered rate. Secret exposure, phishing, password reuse, a weak recovery flow, credential stuffing, implementation defects, or a biased generator can create faster routes. Rates and hardware can also change. Treat the number as a scoped scenario that needs periodic review.
Why does the calculator show both exact combinations and approximate time?
The combination count is an integer determined by the alphabet and length, so the calculator builds and displays it exactly. Time calculations require division by a potentially fractional rate and readable unit conversion; they are therefore rounded estimates. Keeping both makes the source of the approximation visible.
Can I use this to plan recovery codes or API tokens?
Yes, when the codes or tokens are uniformly generated and you model only their unpredictable portion. Also consider expiration, one-time use, scope, revocation, endpoint throttling, logging, storage, and accidental disclosure. A strong search space is valuable, but token lifecycle controls determine the broader risk.
References
The calculation is a transparent mathematical planning model. The security guidance below provides current U.S. federal context for password length, rate limiting, blocklists, verifier handling, and practical password choices.
- NIST Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
- National Institute of Standards and Technology, “How Do I Create a Good Password?”
Educational use only. This calculator does not provide authorization to test any account, service, device, or dataset. Use measurements only in systems you own or are explicitly permitted to assess.