Brute Force Cost Calculator

You picked a password, but how much would it actually cost someone to break it? This brute force cost calculator turns your password's length and character set into a hard number: how many hours or years a GPU rig needs, and how many dollars of rented hardware it burns. Instead of a vague "weak" or "strong" label, you get a price tag you can compare against what your account is worth to an attacker.

What a Brute Force Cost Calculator Measures

A password's real strength is the effort an attacker has to spend, and that effort has two parts: time and money. A cost calculator for this job multiplies the number of possible passwords by the speed of the attacker's hardware, then converts the hours of compute into dollars at a rental rate. The same brute force cost calculator logic works for any secret with a fixed alphabet, whether it is a long passphrase or a short numeric code, because every guess is just one more hash to compute. The password reuse checker checks your input against current best practices and flags anything worth fixing.

Think of it as a receipt rather than a score. A strength meter only reacts to the shape of your password, while a brute-force calculator reacts to the hardware and the hashing method protecting it, which is exactly what changes the answer by orders of magnitude.

Offline attack versus online attacks

The number only makes sense for the right scenario. Online attacks happen against a live login form, where rate limits, a lockout after a handful of wrong tries and network latency cap an intruder at a few guesses per second. An offline attack is different: after a data breach, the attacker holds a copy of the stolen password hashes and can test candidates on their own machines at full speed, with no server watching and no account to lock. Every figure on this page models that offline case, because offline attacks are the worst case a defender has to plan for.

The conclusion for your security planning is simple: you cannot count on a login screen to protect you once the database has leaked. Only the secret's own difficulty and the slowness of the hashing method remain.

The Brute-Force Cost Formula

The brute-force cost comes down to three multiplications and a division. First you size the space of every password the attacker may need to try. Then you divide by how fast the hardware tests them. Finally you convert the running time into rental money. Run the quantum resistance estimator to double-check a result before you rely on it for something important.

$$\text{Keyspace} = N^{L} \qquad \text{Time} = \frac{N^{L}}{R} \qquad \text{Cost} = \frac{\text{Time}}{3600} \times P$$

Here \(N\) is the alphabet size, \(L\) is the password length, \(R\) is the attacker rate in guesses per second and \(P\) is the rental price per hour for the whole rig. Because a lucky attacker finds the secret before the sweep ends, the expected time is half of the full sweep on average.

Keyspace and search space

The keyspace is the total number of combinations that can be built from your alphabet at your length. Mathematicians also call it the search space. A password drawn from lowercase letters, uppercase letters and digits has an alphabet of 62 characters, so every extra position multiplies the space by 62. Adding special characters pushes the alphabet to around 95 printable symbols and raises the multiplier further.

• Lowercase only: 26 symbols per position.
• Lowercase plus uppercase: 52 symbols.
• Letters plus numbers: 62 symbols.
• All printable ASCII, including special characters: about 95 symbols.

Attacker rate and hashrate

The hashrate is how many hashes per second the hardware completes, and for brute force it equals the number of guesses per second. It depends on two things at once: the card and the hash function being attacked. A fast general-purpose function such as MD5 lets a single GPU test tens of billions of candidates every second, while a deliberately slow function with a high work factor reduces the same card to thousands. The rate you enter is the single most important input, so treat the rates below as assumptions to replace with a benchmark from your own hashcat run.

Worked Example: Password Cracking of a 9-Character Password

Suppose a company leaks its user table, and one customer's password is nine random characters from letters and digits, stored as an unsalted MD5 hash. The attacker rents a rig of eight RTX 4090 cards. We assume each card manages 150 billion MD5 guesses per second, and that the cloud provider charges $2.20 per GPU-hour. Those are illustrative assumptions for this walkthrough, not quotes from any provider.

The answer is sobering: a random nine-character password protected only by MD5 falls in about an hour and a half for roughly twenty-eight dollars. The password looks complicated to a human, yet the entropy of 53.6 bits is tiny next to the power of rented hardware. Run through the formula: \(62^{9} \div 1.2\times10^{12} \approx 11{,}281\) seconds, then \(11{,}281 \div 3600 \times \$17.60 \approx \$55.15\).

How Hash Algorithms Change the Time to Crack

The same nine characters can be cheap or impossible to recover, depending on the hash. A fast hashing algorithm was built to digest files quickly, which is the opposite of what you want for stored passwords. Slow ones such as bcrypt, PBKDF2 and Argon2id are tuned with a cost parameter so that every single guess takes real effort, and that is the key stretching that protects users after a leak.

Other legacy functions behave like the fast ones. SHA1 and NTLM hashes, the kind found in old Windows environments, can be tested at speeds comparable to MD5, so a stolen dump of those is nearly as dangerous. Moving from MD5 to SHA-256 changes the bill by a factor of about seven, but moving to a memory-hard or iterated function changes it by a factor of millions. When you choose how to store credentials, the hash settings matter more than any rule you impose on users.

In hashcat, the mode number selects the function being attacked (for example -m 0 for MD5 and -m 3200 for bcrypt), and its built-in benchmark prints the rate for your card, which is the number you should feed into any cost calculator.

Picking a Hardware Profile for the Offline Attacker

An offline attacker is only as dangerous as the equipment behind them. A hardware profile bundles a device with its measured speed per hash type, so you can compare a laptop with a rack. A consumer RTX 4090 is the common reference point, and a newer RTX 5090 raises the rate further. An aging CPU falls far behind either card, which is why a laptop is rarely the realistic threat.

The third option is renting capacity in the cloud. An AWS GPU instance is billed by the hour, and its spot prices fluctuate with demand, so the same job can cost noticeably less when the attacker is patient. A reasonable planning habit is to model your own worst case with a multi-GPU rig, because attackers who steal a hash dump choose the cheapest effective option, not the average one.

No single speed fits every threat, so a simulation across several profiles gives a range rather than one figure. Your compute budget estimate is only as good as the rates behind it, and the calculator makes that assumption visible instead of hiding it.

Password Length, Entropy and Complexity

Length beats cleverness. Every extra random character multiplies the keyspace by the alphabet size, which is why the bill for the same MD5 rig climbs so steeply with each added position.

Combinatorial explosion

This runaway growth is the combinatorial explosion that makes exhaustive search hopeless beyond a certain size. Each added position gives a 62-fold jump, so three extra characters make the job a quarter of a million times harder. The complexity that users feel, such as adding a symbol, helps far less than the plain count of characters.

The security level of a random password is its entropy in bits, \(L \times \log_2 N\). Nine characters from 62 symbols give 53.6 bits, while twelve give 71.4 bits. Each bit doubles the work, so this number is a compact way to compare complex passwords of different shapes, and it feeds directly into the guess count the calculator needs.

Dictionary words, leetspeak and zxcvbn

Entropy assumes the password is random, and human choices rarely are. A dictionary attack tries real words first, and clever substitution known as leetspeak, as in swapping an "a" for "@", adds almost nothing because rule sets already cover it. A consecutive pattern such as "123456" is among the first things hackers try, and a keyboard walk falls just as fast.

That is where a pattern-aware estimator earns its keep. The zxcvbn library scores the guesses a human-style password would really need, and feeding that number in place of raw length gives a far more honest password strength reading. You can also check whether the password already appears on Have I Been Pwned, since a breached password is compromised regardless of its entropy, and a tool that uses zxcvbn alongside that check covers both weaknesses.

Checking a Leaked SHA-1 Dump With a Brute-Force Calculator

Imrana Okafor runs IT for a 40-person accounting firm. A payroll vendor has just disclosed a breach, and the exposed file holds unsalted SHA-1 hashes of her staff's passwords. The firm's policy asks for 10 characters from lowercase letters and digits, so the alphabet is 36 symbols. She wants to know whether to force resets today or at the end of the week.

She enters 36 for the alphabet and 10 for the length, and the keyspace comes out at \(36^{10} = 3{,}656{,}158{,}440{,}062{,}976\) guesses. For the attacker she picks a rented rig of four GPUs at an assumed 60 billion SHA-1 guesses per second each, so 240 billion per second, billed at $1.90 per GPU-hour, or $7.60 an hour. The brute-force estimate arrives instantly: 15,234 seconds, which is 4.23 hours, and a rental bill of $32.16 for the full sweep.

The 51.7 bits of entropy clear the 8-character minimum in NIST SP 800-63B, yet a $32 bill is far below what a stolen payroll login is worth, so she does not wait. She forces resets that afternoon. Then she reruns the calculator with the length changed to 14 and nothing else, which gives 72.4 bits, 811 years and about $54 million, and she writes 14 characters into the new policy. She also asks the vendor to move from SHA-1 to bcrypt, because the hash, not the length alone, set the price.

Reading the Price Tag in USD

Dollars give you a decision rule that years do not. If cracking an account costs less than the account is worth, a motivated criminal will pay it, so the price tag should exceed the value of what the password guards. A $55 bill protects almost nothing, while a bill in the millions or billions protects nearly any consumer account. The result in USD is also easy to explain to colleagues who do not follow the hash maths.

• Under about $100: assume the secret is already broken.
• Thousands of dollars: acceptable only for low-value accounts.
• Millions and beyond: the attacker will go after something easier, such as a reused password or a phishing page.

Keep in mind that rental cost is a floor, not a ceiling. Attackers who already own GPUs pay only for electricity, and a small group sharing resources divides the hours between them.

PIN Brute-Force Calculator: Short Secrets and Device Binding

A four-digit code has only 10,000 possible values, so an offline sweep against it finishes almost instantly unless something slows each guess. A PIN brute-force calculator runs the same arithmetic with a 10-symbol alphabet and a short length, and it shows that the iterations of a function like PBKDF2 only buy a limited delay against such a small space.

The strongest fix is device binding: the key derivation mixes in a per-chip secret that cannot be copied out of the hardware, so a stolen dump is useless away from the original device and the offline sweep is no longer possible. For a cost estimate that means the guess rate you enter no longer applies once the secret is bound to the chip. That is a design decision for engineers, not something a user can add, but it explains why phones tolerate short PINs while a leaked web database does not.

Limits of a Brute-Force Search Estimate

Every brute-force search estimate is an upper bound on effort for a patient, unlucky attacker, so read it with the following caveats in mind. They matter whenever you turn the figures into policy.

• It assumes the secret is chosen uniformly at random. Human-chosen passwords fall much sooner.
• It assumes one speed. Real attackers combine several machines, and each new GPU generation lifts the rate.
• It ignores salting details, hash settings and memory costs that vary between systems.
• A brute force attack is only one route. Brute-force attacks compete with phishing, malware and password reuse, which cost the attacker almost nothing.

A calculator also runs in your browser with simple arithmetic, so nothing you type has to leave your machine, and you should still avoid entering a real password into any web page. Use a representative pattern of the same length and character set instead.

Turning the Result Into Better Password Security

Use the numbers to decide what to change. For people, the cheapest upgrade is length: a random 14-character password or a passphrase of several words beats any algorithm-driven complexity rule, and a password manager removes the burden of remembering it. For developers, choose a slow hash such as Argon2id or bcrypt with a work factor that keeps each login under a fraction of a second, add a unique salt and rate-limit the login endpoint. For any account that matters, turn on a second factor.

The cybersecurity lesson is that risk depends on three things together: the secret, the encryption or hashing around it, and the infrastructure budget of the attackers. A secure choice on one side can be undone on the other, and a dollar estimate shows which side is the weak link, which is cryptography expressed in the one unit everyone understands: money. A random, long secret is fine where a short one stays vulnerable, and any server with a login page should be treated as a future leak, since a hacker only needs one dump. The time spent on this check is well spent.

Frequently Asked Questions

What does "effective rate" mean here?

It's the raw GPU hash rate divided by the number of hashing iterations -- e.g. a GPU that computes 22 billion raw SHA-256 hashes per second can only test about 628,000 candidate passwords per second against a password hashed with 35,000 PBKDF2 iterations, since each guess requires running the hash function that many times.

Why does the iteration count matter so much?

It's one of the single biggest factors in real-world crack resistance -- properly configured PBKDF2/bcrypt/scrypt/Argon2 deliberately slow down each guess attempt by thousands to millions of iterations, turning a GPU's raw billions-of-hashes-per-second speed into a much smaller effective guesses-per-second rate. A site using an unsalted, un-iterated hash (or worse, storing plaintext) offers none of this protection.

Are these GPU hash-rate figures accurate?

They're based on commonly cited raw SHA-256 benchmark figures for each card (the same figures published in hashcat and mining benchmarks) as of when this tool was built -- treat them as reasonable estimates, not live real-time figures. Use the Custom option to plug in your own measured or updated rate.

What's the difference between average and worst-case time?

Worst-case is the time to exhaust the entire possible combination space; average-case assumes the correct password is found, on average, halfway through that space -- which is the standard way crack-time estimates are usually presented, since an attacker isn't guaranteed to need the full search.

Is this calculation sent anywhere?

No. Every calculation runs entirely in your browser using simple arithmetic -- nothing is transmitted to a server or stored.