Password Summer2026! appears strong with an uppercase letter, digits, a special character and sufficient length for many registration forms. Yet cracking programs can test such a pattern much earlier than a short random sequence because people create passwords according to recognizable templates that tools are designed to reproduce.
Hashcat and John the Ripper help recover forgotten passwords and evaluate account protection. Results depend on the storage algorithm, hardware and the order in which candidates are tested. Work should be performed only on authorized copies during agreed audits.
What Happens During Password Guessing
Services rarely store passwords in plaintext. At registration the application computes a verification value using a one-way function; on login it repeats the computation for the submitted password. A match grants access. The stored record is commonly called a hash even though it may also contain the algorithm name, salt and computation parameters.
Hashing differs from encryption because no key exists to reverse the operation. The cracking program proposes a candidate, performs the required computation and compares the result with the stored value. Weak passwords can be guessed without inverting the hash function. Known collision issues in MD5 and SHA-1 do not enable instant recovery of arbitrary passwords.
Plain MD5, SHA-1 and SHA-256 compute too quickly for direct storage of human passwords. Even cryptographically strong SHA-256 without a dedicated password scheme permits millions of guesses. Protection therefore requires functions that deliberately consume CPU time and, in modern variants, significant memory.
Why Salt and Expensive Computations Matter
A salt is a random value generated separately for each password entry and stored alongside the result. Different salts produce different verification values even for identical passwords and prevent precomputed tables from being reused across an entire database.
With unsalted hashes of the same type a program computes each candidate once and compares it against many records. Different salts force repetition of the expensive work for every salt. The claim that a million records always takes exactly a million times longer is incorrect; time depends on the number of unique salts, function parameters, hardware, discovered matches and computation organization.
Bcrypt uses a cost parameter that exponentially increases computational complexity. Moving from cost 10 to cost 12 multiplies the main workload by roughly four. Argon2id cost is influenced by memory size, number of passes and parallelism. Algorithm names alone are insufficient to assess protection.
Common Formats Encountered Today
Before starting, the exact contents of the file must be identified. A 32-character hexadecimal string may represent MD5, an NT hash or another value. Record origin, application source code and the complete format are more reliable than automatic detection.
- NT hash (mode 1000): MD4 of the password in UTF-16LE without salt, common in Windows password storage.
- NetNTLMv2 (mode 5600): network authentication response data requiring additional exchange fields.
- sha512crypt (mode 1800): salted repeated SHA-512 computation, usually prefixed $6$.
- bcrypt (mode 3200): salt and cost embedded in the record, often prefixed $2a$, $2b$ or $2y$.
- phpass (mode 400): legacy records prefixed $P$ or $H$, still used by older WordPress installations.
- Argon2id and yescrypt: memory-hard schemes whose exact support must be verified in the build.
Current Linux distributions including Debian, Ubuntu and Fedora have adopted yescrypt (prefix $y$) while older sha512crypt records persist until passwords are changed. WordPress 6.8 now uses bcrypt with SHA-384 preprocessing; new records begin with $wp$2y$.
Preparing Data and Tools
Hashcat excels at rule-based and mask attacks on compatible hardware. John the Ripper Jumbo offers broad format support and extraction utilities. Always work on copies, retain full records including salts and iteration counts, and validate the chosen mode against a known test password.
Why GPUs Do Not Always Deliver Maximum Speed
GPUs parallelize many identical independent computations efficiently for fast hashes. Memory-hard algorithms such as Argon2id, scrypt and yescrypt limit throughput because of memory bandwidth and access patterns. Built-in benchmarks provide baseline figures but real runs on the target set remain necessary.
Dictionaries, Rules, Masks and Statistical Models
Dictionary attacks test existing wordlists while rules transform each entry (case changes, digit insertion, character substitution). Masks describe character sets per position, for example ?u?l?l?l?l?d?d?d?d. Combined modes (-a 6, -a 7, -a 1) and multiple rule files multiply the candidate space rapidly. Markov models and neural generators produce probable passwords from training data but still require verification of every candidate.
Encoding and Length Limits
Passwords pass through several representations: user-visible characters, file bytes and algorithm-specific encodings such as UTF-16LE for NT hashes. Bcrypt commonly limits input to 72 bytes, reached earlier with Cyrillic text. The -O flag in hashcat can further restrict supported lengths for speed.
Interpreting Results and Avoiding Self-Deception
Status “Exhausted” only means the supplied candidate set finished; it does not prove remaining passwords are strong. The potfile records recovered pairs and should be managed carefully. Audits must log algorithm, parameters, record counts, hardware, software version and runtime. Debug options reveal which rules succeeded.
Actions After Testing
New applications should adopt Argon2id with parameters tuned to acceptable login latency. Records should be recomputed on successful login or password change. Long unique passphrases stored in managers outperform periodic complexity rules. Windows environments additionally require protection against Pass-the-Hash attacks even when the original password remains unrecovered.
