Calculate Brute-Force Crack Time — Free Cost Calculator

Why Password Strength Alone Doesn't Tell the Full Story of Account Protection

Online vs Offline Attacks: A Critical Distinction

The difference between online attacks and an offline attack is the difference between a thief testing a lock one click at a time and a thief who has taken the lock home to a laboratory. In online attacks, the adversary submits guesses through a live authentication endpoint — they're constrained by network latency, rate limiting, account suspension policies, and CAPTCHA challenges. Most services enforce an access block after a handful of wrong tries, making exhaustive online guessing a viable defense. Online guessing against a well-configured server is effectively infeasible.

An offline password attack is an entirely different threat model. When a threat actor gains access to a dumped database — whether through a data breach, a flash dump from an embedded device, or an exfiltrated vault — they take the hashed credentials offline and run an automated program across powerful computers at full GPU throughput. There is no rate limiting, no suspension, no server to stop them. A criminal can test candidates at billions of guesses per second using rtx-4090-class hardware, turning a weak credential into a match found in mere moments.

A Note on Realism: Iteration Count and Hash Cracking Speed

Real-world adversary budgets are constrained by the cost of GPU computing time and electricity. This is exactly what the cost calculator makes visible. Two factors dominate the calculation:

1. Key stretching — algorithms like bcrypt and PBKDF2 use key derivation to force each guess to consume many hash operations. A bcrypt cost factor of 12 means each candidate requires ~4,096 SHA-like rounds, slashing the effective guess rate by orders of magnitude compared to raw md5. The PBKDF2 work factor setting controls this directly.
2. GPU hashrate — an rtx-4090 achieves roughly 164 billion MD5 hashes per second but only about 184,000 bcrypt hashes per second at cost factor 12. That 900,000× difference in throughput translates directly into 900,000× higher adversary cost.

The pattern-detection library adds another layer of realism by recognizing that a credential following a recognizable pattern like a birthdate, a name123 format, or consecutive number sequences carries far fewer effective combinations than its character count implies. A password strength score from this analysis accounts for these shortcuts; a naive entropy calculation does not. The --hibp flag additionally checks whether a credential appears in known breach datasets, flagging any exposed password before it reaches production — supporting identity protection by catching reused or compromised secrets.

How the Calculator Works: From Password Strength Test to Dollar Figure

Password Strength Table: Weak vs. Strong at a Glance

The following password strength table illustrates how length and password complexity, hash algorithm choice, and character set interact to produce wildly different crack time and cloud cost outcomes. All cost estimates assume an rtx-4090 GPU profile with bcrypt at cost factor 12 unless otherwise noted. This reference chart is a starting point — your actual numbers will vary based on the GPU profile and hash algorithm you select in the tool above.

The pattern is clear: a 16-character password takes an adversary a billion years to crack under bcrypt, while a shorter 8-character equivalent will take anywhere from a few hours to several weeks under MD5. The password strength calculations behind these numbers rely on reliable computations anchored to published GPU benchmark data — not guesswork.

Let's Walk Through Real Password Examples: Crack Password Step by Step

The following three worked examples show the full pipeline the brute force cost calculator runs under the hood. Each one illustrates a different point about credential protection and account protection.

Example 1 — Easy-to-guess password: password123

This is one of the most common easy-to-guess passwords in the ProxyNova and similar breach datasets. It represents the weakest end of the credential quality spectrum.

1. Entropy estimate: The pattern-detection library recognizes the dictionary word "password" followed by a sequential suffix. Effective guess count ≈ 1 × 10⁵ (far below its naive character-count entropy).
2. Adversary rate (RTX 4090, MD5): \(\approx 1.64 \times 10^{11}\) hashes/sec
3. Time to crack: $$T = \frac{1 \times 10^5}{1.64 \times 10^{11}} \approx 6 \times 10^{-7}\text{ seconds}$$
4. Cloud cost (p5.48xlarge instance): Effectively $0.00 — well below any billing increment.

A password cracking attempt on this credential is a trivial risk that exposes your bank account, online accounts, and private information in under a millisecond of GPU time.

Example 2 — Random 12-character password: k9!Lz#mQ2vRp

This is a random credential generated with uppercase and lowercase letters, numbers, and punctuation symbols — the kind a good password generator produces.

1. Character set size: 26 + 26 + 10 + 32 = 94 printable ASCII characters. Secret alphabet of 94 symbols, secret length 12.
2. Keyspace: $$94^{12} \approx 7.5 \times 10^{23}\text{ combinations}$$
3. Adversary rate (RTX 4090, bcrypt-12): \(\approx 1.84 \times 10^{5}\) hashes/sec
4. Duration to sweep: $$T_{\text{sweep}} = \frac{7.5 \times 10^{23}}{1.84 \times 10^{5}} \approx 4 \times 10^{18}\text{ seconds} \approx 130\text{ billion years}$$
5. Expected crack time: \(\approx 65\) billion years (half of sweep duration).
6. Cloud cost (p5.48xlarge instance): Incalculably large — cracking this credential is an infeasible attack under any realistic adversary budget.

Example 3 — bcrypt passphrase vs. MD5 passphrase: Same secret, different hash algorithm

Consider a six-word passphrase with an estimated guess count of \(10^{16}\) (accounting for pattern-aware analysis). This example directly compares the impact of hash algorithm choice — the core lesson in understanding offline attacks.

1. MD5 adversary rate (RTX 4090): \(1.64 \times 10^{11}\) hashes/sec $$T_{\text{MD5}} = \frac{10^{16}}{1.64 \times 10^{11}} \approx 60{,}000\text{ seconds} \approx 17\text{ hours to crack}$$ Cloud cost: ~$4.80
2. bcrypt (cost factor 12) adversary rate (RTX 4090): \(1.84 \times 10^{5}\) hashes/sec $$T_{\text{bcrypt}} = \frac{10^{16}}{1.84 \times 10^{5}} \approx 5.4 \times 10^{10}\text{ seconds} \approx 1{,}700\text{ years}$$ Cloud cost: ~$153,000,000

Same credential. Same guess count. The difference in key-stretching iterations between md5 and bcrypt — what cryptography practitioners call the work factor — multiplies the adversary's cost by nearly 900,000×. This is why hashing algorithm choice is not an implementation detail — it is a primary control in your data protection architecture.

Easy-to-Guess Passwords: The Hidden Cost to You (Not the Attacker)

The irony of easy-to-guess passwords like 123456, a birthdate credential, or a name123 sequence is that the cost is near-zero for the adversary and catastrophic for you. A credential stuffing attack takes a list of breached username-password pairs and systematically tries them across hundreds of online accounts — your email, online subscriptions, online profile, even customer accounts at services like Dunkin' Brands (which was fined after a data breach stemming from credential stuffing). Once a threat actor finds a match from a previous breach, every account sharing that reused credential is exposed.

Password vulnerability is not theoretical. It is a measurable attack surface with a computable cost — and the password cracking cost to the adversary is what this tool is designed to make visceral. Weak credentials that take mere moments to crack represent a thin line between your digital identity protection and a data breach that could cost you login credentials, exposure to fraud, or worse.

Using brtc as a CI/CD Gatekeeper in DevSecOps Development Workflows

The most powerful use case for the CI/CD gatekeeper mode is integrating brtc directly into your CI/CD pipeline to enforce credential policy at build or deploy time. This is a form of automated enforcement that catches weak passwords before they ever reach a production environment — a core principle of DevSecOps and shift-left tooling.

Privacy: Is Anything Sent to a Server? (Password Security Guarantee)

No. Every calculation is browser computed or runs locally in your terminal process. All credential evaluations are locally processed — no input is ever transmitted to any external server, and your credentials never leave your machine. This applies equally to the breach-check flag, which uses k-anonymity to query breach databases by sending only a partial hash prefix, never the full credential. The tool is open source and you can audit it line by line.

To integrate brtc as a policy enforcer in a GitHub Actions workflow:

- name: Password policy enforcement
  run: |
    npx brtc \
      --zxcvbn \
      --hibp \
      --minimum-password-length 16 \
      --gpu rtx-4090 \
      --hash bcrypt \
      --iterations 100000 \
      "${{ secrets.TEST_PASSWORD }}"

In report-only mode, add --report-only to run the full credential audit and output insights without failing the build — ideal for brownfield projects where you want to measure quality before enforcing minimum standards. This supports a gradual rollout of policy enforcement without breaking existing pipelines.

For teams working on embedded systems or IoT firmware, the tool is particularly valuable when modeling the offline attack threat against devices like an ESP32 microcontroller. A processor running PBKDF2 with high iteration count provides meaningful key stretching, but only device binding — mixing a per-device secret sealed in hardware-protected storage — makes an offline guessing attack truly infeasible. Even with PBKDF2 pbkdf2 work factor cranked high, an adversary who has obtained a dumped flash or exfiltrated vault can still sweep keyspace offline unless the key derivation requires access to a per-device secret that cannot be extracted from flash storage. This is the attack simulation the tool models most precisely for embedded hardware contexts.

CI integration also supports contributor guidelines for open source projects. Teams can document the minimum credential length, required hash algorithms, and GPU profile assumptions in a .brtc.config file committed to the repository. New contributors and automated pipeline runs reference the same configuration, ensuring consistent credential auditing across the entire development workflow. The tool's license is permissive for both commercial and open source use — check the releases and changelog in the repository for the latest version and any updates to the hardware profiles or cloud GPU cost tables.

For penetration testing and threat modeling exercises, brtc provides a rapid attack simulation baseline. Instead of manually computing GPU throughput and cloud infrastructure money costs, defensive teams can run the tool against a full credential set and immediately see which passwords represent a realistic attack vector and which are genuinely protected by their length, randomness, complexity, and algorithm choice. This kind of credential auditing informs policy decisions with concrete data — not instinct — and it's the foundation of sound credential management at both the individual and enterprise level.

Network teams evaluating authentication systems can use the tool's output to quantify the infrastructure cost an adversary would need to sustain a prolonged exhaustive attack. Understanding that cracking a bcrypt-hashed 16-character credential on a high-end cloud instance would cost tens of millions of dollars in computing fees makes the ROI of strong credential policy immediately legible to non-technical stakeholders. That translation — from abstract cybersecurity guidance to concrete financial cost — is why this brute force cost calculator belongs in every engineer's toolkit.