Password cracking is the process of recovering a plaintext password from its stored hash by guessing candidates and comparing their computed hash against the target — using dictionaries, rule-mutated wordlists, mask patterns, or brute force, accelerated by GPU hardware running tools like Hashcat. It matters to defenders because the same techniques attackers use to crack a stolen hash dump are exactly what you should run against your own password database first. A fast hash like MD5 or SHA-1 can fall in hours on consumer GPUs; a properly salted bcrypt or Argon2 hash resists the same attack for years. This guide covers how offline cracking works and what defensible password storage looks like for an Indian SMB.
Why Offline Password Cracking Matters to Defenders
Most password compromise doesn't happen by guessing a login form one attempt at a time — modern web apps rate-limit that. It happens offline, after a database breach, when an attacker walks away with a table of hashed passwords and cracks them at leisure, with no rate limit, no lockout, and no logging. Understanding this offline process reframes the real question from "is our login page secure" to "if our hash table leaked today, how long would it survive."
Step One: Capturing and Identifying the Hash
An attacker's first move after any breach — SQL injection, misconfigured backup, leaked .env file, insider dump — is grabbing the credentials table. A raw hash string is useless without knowing its type, since each algorithm needs a different cracking mode. A 32-character hex string is almost certainly MD5; a 40-character hex string is SHA-1; a string beginning $2a$, $2b$, or $2y$ is bcrypt; one beginning $argon2 is Argon2. Hashcat ships an --identify mode, and tools like hashid do the same job on large mixed dumps.
hashcat --identify hashes.txtGetting the mode number right matters: Hashcat maps each algorithm to a specific -m value — 0 for raw MD5, 100 for SHA-1, 3200 for bcrypt, 22000 for WPA/WPA2 handshakes — and the wrong mode simply fails silently or wastes GPU time on comparisons that can never match.
The Four Attack Modes: Dictionary, Rule-Based, Mask, and Brute Force
Hashcat organises cracking strategy into distinct attack modes, and picking the right one — usually in sequence, cheapest first — separates an efficient audit from one that burns days of GPU time for nothing.
- Dictionary attack (
-a 0) — tries every entry in a wordlist as-is. Wordlists likerockyou.txt(14 million real passwords leaked from a 2009 breach) remain effective because human password choices repeat across sites and years. - Rule-based attack (
-a 0 -r rules/best64.rule) — applies transformation rules to each dictionary word: capitalise first letter, append123, swapafor@, add a trailing!. This mimics exactly how real users "strengthen" a base word, and it is often the single highest-yield technique against real-world password sets. - Mask attack (
-a 3) — brute-forces a defined pattern, such as?u?l?l?l?l?d?d?d?dfor "one capital, four lowercase, four digits," which matches common formats likeDelhi2024. Masks are far more efficient than blind brute force because they eliminate character-space combinations that never occur in practice. - Combinator and hybrid attacks (
-a 1,-a 6,-a 7) — combine two wordlists, or a wordlist with a mask, catching patterns likecompanynameplus a four-digit year.
hashcat -m 0 -a 0 hashes.txt rockyou.txt -r rules/best64.ruleKnow your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanWhy GPU Speed Turns Fast Hashes Into a Liability
The reason offline cracking is so effective against certain hash types comes down to raw computational speed. General-purpose hashing algorithms like MD5 and SHA-1 were designed for speed and data-integrity checks, not for resisting brute force — and that speed is precisely what makes them dangerous for password storage. A modern consumer GPU can compute billions of MD5 hashes per second, meaning an eight-character password from a reasonable character set can be exhausted in hours, not years.
Purpose-built password hashing functions — bcrypt, scrypt, and Argon2 — are deliberately slow and memory-hard. Bcrypt has a tunable cost factor multiplying computation per attempt; Argon2 additionally forces high memory usage, defeating the parallel-GPU advantage that makes fast hashes cheap to crack at scale. A GPU computing billions of MD5 hashes per second might manage only a few thousand Argon2 hashes at a tuned cost factor — orders of magnitude turning an hours-long crack into one that is computationally infeasible.
| Hash function | Design purpose | GPU cracking resistance | Recommended for passwords |
|---|---|---|---|
| MD5 | Data integrity checksum | Very low — billions of hashes/sec on GPU | No |
| SHA-1 / SHA-256 | General-purpose cryptographic hash | Low — fast by design, GPU-friendly | No, unless heavily stretched |
| PBKDF2 | Key derivation, iterable stretching | Moderate — depends entirely on iteration count | Acceptable with high iteration count |
| bcrypt | Purpose-built password hash | High — tunable cost factor slows GPU attacks | Yes |
| Argon2id | Purpose-built, memory-hard | Very high — memory cost defeats GPU parallelism | Yes, current best practice |
Salting: Why Identical Passwords Must Never Produce Identical Hashes
A salt is random data unique to each password, combined with the password before hashing, so two users with the identical password "Password123" produce two completely different stored hashes. Salting defeats precomputed rainbow-table lookups outright, and forces an attacker to crack every hash individually rather than cracking one common password once and matching it across every account that shares it. Bcrypt and Argon2 handle salting automatically; with PBKDF2 or a custom scheme, the salt must be generated with a cryptographically secure random generator, stored per-record, and never reused across users.
Password Length, Complexity, and the Diminishing Returns of Rules
Length matters more than forced complexity. A mandatory mix of uppercase, digits, and symbols pushes users toward predictable patterns — Password1! — that rule-based attacks target, while a longer passphrase from unrelated words expands the keyspace far more than a shorter "complex" string. Current NIST guidance moved away from mandatory rotation and arbitrary complexity toward minimum length (8 minimum, 15+ recommended) plus screening against known-breached password lists.
Each added character multiplies the keyspace an attacker must search, which is why length gives a steeper defensive return than one more mandatory symbol on an already-short password.
Defence: What Actually Stops This Attack Chain
Understanding the attack side matters only if it changes what you build. The controls below turn a hash dump from "cracked within hours" into "not worth the compute."
- Hash with Argon2id or bcrypt, never MD5, SHA-1, or unsalted SHA-256, for any credential store.
- Salt every hash uniquely using a cryptographically secure random generator, and never reuse a salt across users or deployments.
- Enforce minimum password length (12+ characters recommended) over arbitrary complexity rules.
- Screen new passwords against known-breached password lists at signup and reset, rejecting matches outright.
- Require multi-factor authentication (MFA) so a cracked or leaked password alone isn't sufficient for account takeover.
- Monitor for credential-stuffing patterns — repeated login attempts using previously breached username-password pairs — since a cracked dump routinely gets replayed against unrelated services.
- Rate-limit and lock out authentication endpoints to blunt online guessing, though it does nothing for an offline hash dump.
Running This as a Defensive Audit, Not an Attack
Security teams run Hashcat against their own hash export to find weak passwords before an attacker does — usually as part of a scheduled internal audit, or one component within a broader external VAPT engagement, delivered with a CERT-In empanelled partner where regulatory submission is required. The output isn't a list of passwords to punish users over; it's a prioritised list of accounts needing a forced reset, and a signal on whether the hashing scheme itself needs upgrading before the next cycle.
DSCI has repeatedly flagged weak credential management as a recurring finding across Indian SMB assessments, and it remains one of the cheapest gaps to close relative to the damage a single cracked admin password can cause once an attacker pivots to lateral access across a network.
Next Steps
Offline password cracking is not a hypothetical — it is the default second step after any credential breach, entirely predictable based on which hashing algorithm you chose. Auditing your own hash storage against Hashcat, in a controlled, authorised way, tells you exactly what an attacker would see before they see it.
Want an independent check on your credential storage and broader attack surface? Get a free VAPT scan, or browse the Bachao.AI blog for more security guides. Bachao.AI, built by Dhisattva AI Pvt Ltd, folds checks like this into a continuous VAPT workflow so weak hashing gets caught before an attacker finds it. If your organisation also handles personal data under India's privacy law, review our DPDP compliance guide.