How password cracking works, why secure hashing matters, what rainbow tables do, and how the technology continues to evolve.
A password can look secure without being particularly difficult to guess.
Take Summer2026!, for example. It contains a capital letter, lowercase letters, numbers and a special character. On paper, it satisfies many traditional password requirements. The problem is that it follows a pattern people use all the time: a familiar word, a year and a symbol at the end.
Password-cracking software is designed to recognise exactly these kinds of habits. With the right hardware and access to poorly protected password hashes, it can test enormous numbers of possible passwords.
This is where tools such as Hashcat and John the Ripper come in.
Over the years, password cracking has developed into a specialised area of cybersecurity. What began with relatively simple techniques on early Unix systems has grown into a field involving graphics processors, sophisticated guessing strategies, mathematical shortcuts and machine learning.
Understanding how these tools work is useful even if you never intend to use them. They reveal why some password-security measures are effective, why others offer little real protection, and why choosing a strong password involves more than meeting a list of character requirements.
The discussion below focuses on the technology and its role in authorised security assessments, research and password recovery.
What Is Password Cracking?
Password cracking is the process of discovering a password by testing possible guesses against information that can confirm whether a guess is correct.
That information might be a stored password hash or verification data from a password-protected document, archive or other system.
Despite the name, password cracking usually doesn't involve decoding a password from some hidden message. Instead, software generates possible passwords and checks them against the available verification data.
The basic process is straightforward:
Generate a possible password.
Process it using the appropriate verification method.
Compare the result with the stored data.
Continue testing candidates until a match is found or the available resources are exhausted.
The practical challenge is deciding which passwords to try and how efficiently they can be tested.
A weak password may be discovered quickly, even when the system uses a relatively expensive password-hashing method. On the other hand, a long, randomly generated password may remain out of reach despite an attacker knowing exactly how the password was stored.
Ultimately, password cracking is a question of probability, computing power, time and cost.
Online and Offline Password Attacks
Not every password attack works in the same way. One of the most important distinctions is whether guesses are tested against a live system or against data held locally.
Online Password Guessing
An online attack involves submitting password guesses to an authentication service, such as a website or application.
Because each attempt passes through the service, the organisation has opportunities to detect and restrict suspicious activity.
Security controls can include login rate limits, temporary delays, monitoring, multifactor authentication and additional verification requirements.
A website might, for example, slow down login attempts after several incorrect passwords or ask for another form of verification.
These measures can make large-scale guessing much more difficult because every attempt must interact with the defender's system.
Offline Password Cracking
Offline cracking presents a different challenge.
In this situation, an attacker has obtained a local copy of password-verification data, perhaps following a database breach.
Instead of sending guesses to the original website, they can test candidates on their own equipment. The website's login restrictions no longer control how quickly those guesses can be checked.
This is one reason secure password storage is so important.
Organisations need to protect password databases from unauthorised access, but they must also consider what would happen if that protection failed.
A stolen password database and an exposed login page create very different security risks.
Understanding Password Hashing
A cryptographic hash function takes an input and produces an output known as a hash or digest.
For a particular algorithm, identical inputs produce identical outputs. Even a small change to the input will normally produce a substantially different result.
Consider these three examples:
harbour
Harbour
harbour!
Although they look similar, each is a different input. Capitalisation, punctuation and even character encoding can affect the resulting hash.
Cryptographic hash functions are designed to make it computationally difficult to determine an input from its hash.
However, passwords create a particular problem.
People often choose passwords from a relatively predictable range of words, names, dates and familiar patterns. An attacker doesn't necessarily need to reverse the mathematical operation. They only need to guess the original password and compare the resulting hash.
If the password is harbour, testing that candidate may be enough to identify it.
Hashing, Encryption and Encoding
These terms are sometimes used interchangeably, but they describe different processes.
Encoding
Changes the representation of information, such as converting data into Base64.
Encryption : Protects information using a cryptographic key.
Hashing :Produces a digest that can be used for comparison and other purposes.
Password hashing : Processes passwords through a deliberately costly verification scheme.
Password guesses can be checked, but each check should require meaningful resources.
A long string of unfamiliar characters doesn't automatically mean information is protected.
For example, a password converted into Base64 can be recovered easily because Base64 is an encoding method, not encryption.
In a properly designed authentication system, passwords should generally be stored using suitable password-hashing methods rather than in a form that can simply be decrypted to reveal the original value.
The OWASP Password Storage Cheat Sheet explains these principles in more detail.
Why Ordinary Hash Functions Are Not Enough
Cryptographic hash functions are often designed to be fast.
Speed is useful when software needs to check file integrity or process large volumes of information. It becomes a disadvantage when the same function is used directly to store passwords.
A fast algorithm allows an attacker to test more guesses in less time.
This is why raw MD5, SHA-1 and SHA-256 should not be treated as modern password-storage solutions.
SHA-256, for instance, remains useful in many cryptographic applications. The problem arises when an application stores passwords using a single, unsalted SHA-256 calculation.
Modern password-hashing schemes address this weakness by making every password check more computationally expensive.
Some also require substantial amounts of memory, increasing the cost of testing large numbers of guesses in parallel.
Common examples include Argon2id, scrypt, bcrypt and PBKDF2.
These algorithms have different characteristics and are suited to different circumstances. OWASP recommends Argon2id for new password-storage systems while recognising that alternatives may be necessary in certain environments.
The aim is simple: make password verification manageable for legitimate users while making large-scale guessing expensive for attackers.
A Brief History of Password Cracking
Password cracking has evolved alongside the computer systems it targets. Many of today's techniques have roots in research carried out decades ago.
Early Computing and Shared Systems
Password security became increasingly important when computers began supporting multiple users.
Early systems exposed some obvious weaknesses, particularly the danger of storing passwords in readable form. Anyone who gained access to those records could potentially obtain every user's credentials.
In 1979, Robert Morris and Ken Thompson published Password Security: A Case History, an influential paper examining the development of Unix password protection.
Their work showed how real attacks could expose shortcomings in security designs and lead to practical improvements.
The lesson remains relevant: protecting passwords requires understanding how an attacker might try to compromise them.
The 1990s: Password Auditing Becomes More Accessible
As Unix systems and computer networks became more common, administrators needed tools to assess the strength of user passwords.
Alec Muffett's Crack, first publicly released in 1991, became an important early example.
The software tested dictionary words and predictable variations to identify weak passwords. Later versions could distribute work across several machines, allowing larger numbers of candidates to be checked.
Muffett's retrospective account of the project describes how software improvements and coordinated computing expanded what was possible with the hardware available at the time.
Crack also helped establish an important principle in defensive security: organisations could assess their own systems using techniques similar to those an attacker might employ.
John the Ripper Enters the Picture
John the Ripper was introduced in 1996 by Solar Designer and later developed with contributions from the wider open-source community.
It became one of the best-known password-auditing tools, particularly among Unix and security professionals.
Over time, its capabilities expanded considerably. Rather than focusing only on a narrow range of Unix password formats, the project developed support for many different types of password-verification data.
Its continued development reflects the changing requirements of security auditing and password recovery.
The 2000s: Rainbow Tables and Precomputation
As password-cracking techniques improved, researchers explored whether some of the required computation could be completed in advance.
The idea was to spend time and storage preparing information that could later speed up password recovery.
Philippe Oechslin's research in 2003 advanced this approach through rainbow tables, building on earlier time-memory trade-off research by Martin Hellman.
Rainbow tables offered a way to balance precomputed calculations, storage requirements and the amount of work needed during a later search.
Although modern security measures have reduced their usefulness in many situations, they remain an important part of password-cracking history.
GPUs Change the Economics
Graphics processing units brought another major improvement.
Originally developed for graphics-intensive tasks, GPUs are also well suited to performing large numbers of similar calculations simultaneously.
This makes them useful for password-verification workloads that can be processed in parallel.
Hashcat became closely associated with GPU-accelerated password recovery. Its move to open source in December 2015 was another significant point in its development.
Across these different generations of technology, the pattern has remained familiar: advances in software, computing hardware and guessing techniques change how much work can be completed within a given time and budget.
Hashcat: High-Performance Password Recovery
Hashcat is a password-recovery and auditing tool known for its performance, broad algorithm support and ability to use hardware acceleration.
Its main strength lies in combining efficient password verification with flexible methods for generating candidates.
Rather than testing only random combinations, Hashcat can work with lists of likely passwords, apply transformations to existing candidates, explore structured patterns and combine different guessing methods.
This flexibility matters because real passwords are rarely distributed randomly.
Imagine an organisation carrying out an authorised password audit. The assessment might reveal that employees frequently choose a familiar word followed by the current year.
The most valuable finding would not simply be that some passwords were recovered. It would be that the organisation's password requirements allowed a predictable pattern to become widespread.
That information could then guide improvements to password policies and authentication practices.
What Hashcat Cannot Do
Hashcat is powerful, but it cannot recover every password.
The outcome depends on several factors:
How unpredictable the password is.
Which verification algorithm is used.
How expensive the algorithm is configured to be.
The hardware and memory available.
How effectively the candidate passwords are generated.
The time and resources available for the assessment.
Performance figures also need context.
A benchmark involving a fast, outdated hashing method tells us very little about the effort required to recover a password protected by a properly configured modern password-hashing scheme.
John the Ripper: Flexibility and Broad Format Support
John the Ripper follows the same general principle of generating possible passwords and checking them against verification data.
What makes it particularly useful is its flexibility and extensive support for different formats.
The original core version and the community-enhanced jumbo edition differ in their capabilities. The jumbo edition supports a wider range of password and encryption formats.
According to Openwall, supported formats include various operating-system passwords, ZIP and RAR archives, 7z files, PDFs, Microsoft Office documents and certain disk-encryption formats.
The exact capabilities and performance depend on the format and software build being used.
John the Ripper is therefore relevant to several legitimate activities, including:
Identifying weak passwords during authorised audits.
Recovering access to encrypted files owned by the user.
Evaluating the security of older document formats.
Conducting controlled security research.
It is sometimes claimed that John the Ripper is primarily a CPU-based tool while Hashcat is a GPU-based tool.
That distinction is no longer particularly accurate. Both projects have evolved, and the John the Ripper jumbo edition includes GPU support.
Their differences are better understood in terms of supported formats, workflows, implementations and the requirements of a particular task.
How Password-Cracking Tools Generate Guesses
Computing power determines how quickly candidates can be tested, but choosing the right candidates is just as important.
A good guessing strategy prioritises passwords that people are more likely to use.
Dictionary Attacks
A dictionary attack tests passwords drawn from a collection of likely candidates.
The word "dictionary" can be misleading because these collections are not limited to ordinary words.
They may include common passwords, familiar phrases, keyboard patterns and other predictable strings.
Examples of password choices that may be represented include:
Months and seasons.
Football teams.
Common first names.
Keyboard sequences.
Familiar expressions.
Dictionary attacks work because people tend to make similar choices when creating passwords.
Some combinations appear far more frequently than others, making them sensible candidates to test first.
Rule-Based Attacks
Rule-based attacks modify existing password candidates.
For example, the word harbour might be transformed into Harbour, harbour1 or Harbour!.
These changes are familiar because they are exactly the kinds of modifications people make when a website requires capital letters, numbers or punctuation.
Unfortunately, these patterns are also familiar to password-cracking software.
Replacing letters with symbols or adding a number at the end may create the appearance of complexity without providing much additional protection.
Brute-Force Attacks
Brute force takes a more systematic approach.
Instead of relying on likely words or human habits, it explores every combination within a defined set of possibilities.
For example, a six-character password using only the digits 0 to 9 has:
10⁶ = 1,000,000 possible combinations.
A 12-character password using 26 possible letters at each position has:
26¹² = 95,428,956,661,682,176 possible combinations.
These figures describe the size of the search space. They do not tell us how long an actual cracking attempt would take.
That depends on the password-verification method, hardware and other operating conditions.
The calculations also assume that characters are selected independently from the available set.
Real human-created passwords rarely follow that model.
Mask Attacks
A mask defines the expected structure of a password.
Suppose an assessment involves passwords known to contain four lowercase letters followed by two numbers.
That information greatly reduces the number of combinations that need to be explored compared with testing every possible character at every position.
Mask attacks demonstrate an important weakness in predictable password formats.
A password can satisfy a complexity requirement while still belonging to a relatively small and easily described search space.
Hybrid Attacks
Hybrid attacks combine different guessing techniques.
A candidate generator might take words from a dictionary and attach structured endings. Another approach could join words together before applying case changes or other transformations.
The goal is to make better use of available computation by testing combinations that are more likely to match real human choices.
Modern password recovery is rarely a simple choice between dictionary attacks and exhaustive brute force.
Statistical Password Guessing
Statistical methods attempt to predict which passwords are most likely to appear.
Rather than treating every possible candidate equally, they use patterns learned from data to decide which guesses should come first.
Examples include:
Markov models, which estimate the likelihood of character sequences.
Probabilistic context-free grammars, which model structures such as words followed by numbers.
Neural models, which learn password patterns from examples.
These techniques do not remove the need to test guesses.
Their value comes from improving the order in which candidates are generated, making it possible to find likely passwords with fewer attempts.
Rainbow Tables Explained
Rainbow tables are a method of reducing password-recovery work through precomputation.
The central idea is that calculations performed in advance may be reused during a later search.
A basic precomputed lookup table could store candidate passwords alongside their hashes.
The difficulty is that such a table becomes extremely large as the number of possible passwords increases.
Rainbow tables address this by using chains of hash operations and reduction functions. Instead of keeping every intermediate value, they store selected information that can later help reconstruct parts of a chain.
A reduction function takes a hash value and converts it into another candidate within a chosen password space.
It does not decrypt the hash or reveal the original password.
During a search, the software attempts to identify a chain that might contain the target hash. It can then reconstruct the relevant sequence to check for a match.
Rainbow tables use different reduction functions at different positions in the chain. This helps reduce some of the problems associated with overlapping chains in earlier time-memory trade-off methods.
The underlying approach is explained in Philippe Oechslin's research.
Why Rainbow Tables Are Less Effective Against Modern Storage
Rainbow tables depend on specific assumptions.
A table created for one hashing algorithm, password length and character set will not automatically work for a different combination.
For example, a table built around short lowercase passwords cannot be expected to recover long, randomly generated passwords.
Unique salts create another important limitation.
When every stored password uses a different salt, precomputed results cannot simply be reused across accounts in the same way.
This substantially reduces the practical value of rainbow tables against properly implemented modern password-storage systems.
Salts, Peppers and Work Factors
These three terms describe different parts of password protection.
Although their names are memorable, their functions are distinct.
Salt
A salt is a value combined with a password during the verification process.
Modern password-storage systems should generate a random, unique salt for each stored password.
This means two users who choose the same password can still have different stored verifiers.
A salt is normally stored alongside the password verifier and does not need to remain secret.
Its purpose is to prevent identical passwords from producing identical stored results and to make reusable precomputation much less useful.
Pepper
A pepper provides an additional secret used in password protection.
Unlike a salt, the pepper must be protected separately from the password database to provide the intended security benefit.
This introduces practical considerations, including how the secret is stored, who can access it and how it can be rotated when necessary.
A pepper can strengthen a password-storage design, but it is not a substitute for using an appropriate password-hashing scheme.
Work Factor
A work factor determines how expensive password verification is.
Depending on the algorithm, relevant settings may include the number of iterations, required memory and level of parallelism.
Increasing the cost of verification can make large-scale password guessing more difficult.
However, organisations must balance security against login performance, system capacity and operational requirements.
These settings should also be reviewed over time as computing hardware improves.
OWASP provides guidance on salts, peppers and work factors in its password-storage documentation.
How Long Does It Take to Crack a Password?
There is no single answer that applies to every password.
Recovery time depends on the password itself, the way it is protected and the resources available to test guesses.
Consider a fictional example.
Suppose a search space contains one trillion possible passwords and a system can test one million candidates per second.
A complete search would require:
1,000,000,000,000 ÷ 1,000,000 = 1,000,000 seconds
That is approximately 11.6 days.
If the correct password is positioned uniformly at random within the search order, it would be found halfway through the search on average.
These numbers are illustrative. They are not benchmarks for Hashcat, John the Ripper or any particular hardware configuration.
Real-world results can differ enormously.
A fast legacy hash may allow guesses to be checked relatively quickly. A modern, expensive password-hashing configuration can make the same number of attempts much more costly.
The guessing strategy matters too.
A familiar human-created password might appear near the beginning of a well-designed candidate list, regardless of how large the complete theoretical search space appears.
This is why password security cannot be judged solely by counting characters and symbols.
First, credential stuffing and password spraying are different from offline password-hash cracking. They target authentication systems in different ways.
Second, a weakness that makes hash collisions easier to find does not necessarily make it easy to recover a particular password.
Finding any two inputs that share a hash is a different problem from finding an input that matches a specific target hash.
What Password Cracking Reveals About Human Behaviour
Some of the most persistent password weaknesses come from the way people try to make passwords memorable.
A common approach is to start with a familiar word, capitalise its first letter, add a date and finish with punctuation.
When forced to change the password, someone might simply increase the number at the end.
These choices are understandable from a human perspective. People need passwords they can remember, often across many different services.
Unfortunately, predictable patterns are exactly what password-cracking tools are designed to exploit.
A password can satisfy every visible requirement of a policy while still being easy to guess.
Length is useful, but the way a password is created matters just as much.
A well-known quotation may be long, yet its familiarity makes it a potentially predictable choice.
Several words selected independently at random have a different security basis from a phrase someone chooses because it is famous or personally meaningful.
Similarly, adding a website name to a password reused elsewhere does not create a genuinely independent secret. It establishes another pattern.
Modern password guidance increasingly reflects these realities.
NIST recommends prioritising password length and checking proposed passwords against lists of commonly used or compromised choices.
Its guidance also rejects arbitrary character-composition rules and advises against requiring periodic password changes without evidence of compromise.
Within NIST's framework, passwords used as a single authentication factor must contain at least 15 characters. Passwords used as part of multifactor authentication may have an eight-character minimum.
These are requirements within that framework, not universal rules governing every website or service.
The Future of Password Cracking
Password-cracking technology continues to develop, particularly in the areas of candidate generation, computing efficiency and authentication design.
Machine Learning and Smarter Password Guesses
Machine learning has been used in password research for years, well before today's widespread interest in generative AI.
One notable example is PassGAN, research first submitted in 2017.
PassGAN explored the use of generative adversarial networks to learn patterns in password datasets and produce new candidate passwords.
The important development was the ability to learn guessing patterns from examples rather than requiring researchers to define every transformation manually.
This does not mean an AI model can look at a hash and instantly reveal the original password.
The model still has to generate candidates, and those candidates still need to be checked using the relevant verification method.
Strong random passwords and expensive password-hashing schemes remain substantial obstacles.
Claims about AI cracking passwords instantly should therefore be treated with caution.
A meaningful assessment needs to explain which passwords were tested, how they were protected, what hardware was used, what data informed the guessing strategy and how many attempts were available.
Without that context, dramatic performance claims offer little useful information.
Making Better Use of Every Guess
Future improvements are likely to involve better coordination between different candidate-generation methods.
Traditional rules, statistical models and neural networks can produce overlapping guesses.
Combining these approaches more effectively may reduce duplicated work and help tools prioritise promising candidates.
The likely direction is greater efficiency rather than one universal technique replacing every existing method.
Password recovery will continue to depend on the particular problem being solved.
Increasing Pressure on Legacy Password Storage
As computing hardware improves, outdated password-storage practices become harder to justify.
Systems that rely on weak legacy methods may become increasingly vulnerable to affordable offline guessing.
At the same time, defenders can respond by using appropriately configured password-hashing algorithms that increase the cost of each verification attempt.
The resulting competition is not simply about raw processing speed.
Memory requirements, energy consumption, parallelism and hardware costs all influence what is practical.
Better computing hardware benefits attackers, but improvements in password-storage design can raise the resources required for an attack.
Passkeys Change the Problem
Passkeys offer a different approach to authentication.
Instead of relying on a shared password, they use public-key cryptography.
The service stores a public key, while authentication relies on proving possession of the corresponding private key.
The FIDO Alliance describes passkeys as phishing-resistant credentials intended to replace passwords.
This matters because correctly implemented passkey authentication avoids the familiar problem of a website storing password hashes that could later be stolen and tested offline.
If an attacker obtains the service's public-key records, those records do not provide the same opportunity to guess users' passwords.
Passkeys do not eliminate every authentication risk.
Organisations still need to secure account recovery, user devices, sessions and any fallback login methods.
Nevertheless, removing the shared password changes the underlying security problem in a meaningful way.
Quantum Computing and Password Security
Quantum computing is sometimes described as a technology that will eventually break every password almost instantly.
That claim overlooks important practical limitations.
Quantum search algorithms offer theoretical advantages for certain computational problems, but their real-world impact depends on the capabilities of the hardware, error correction and the type of computation involved.
There is no single, meaningful quantum cracking time that applies to every password or password-hashing method.
For most organisations, existing problems deserve more immediate attention.
Weak passwords, credential reuse and outdated password storage present measurable risks today, regardless of what quantum computing may eventually make possible.
What Organisations Can Learn from Password-Cracking Tools
The value of password-auditing tools lies in what organisations do with the findings.
A successful assessment should lead to improvements in security, not simply produce a count of recovered passwords.
An authorised audit can help answer questions such as:
Are employees choosing passwords based on predictable patterns?
Does the organisation use appropriate modern password-hashing methods?
Are password-hashing cost settings still suitable?
Do older applications rely on weaker forms of password protection?
Are password policies encouraging users to make repetitive or easily guessed changes?
A useful security report explains which weaknesses were identified, why they matter and what should be changed.
The number of recovered passwords can provide evidence, but it should not be treated as the only measure of success.
For individual users, the practical advice is straightforward.
Using unique, randomly generated passwords stored in a reputable password manager removes much of the difficulty of creating and remembering strong credentials.
Multifactor authentication provides another layer of protection, while passkeys offer a way to avoid passwords entirely on supported services.
For developers, secure password storage should be a fundamental part of authentication design.
A polished login page and a carefully designed user experience cannot compensate for a database that makes stolen password verifiers inexpensive to attack.
Password protection needs to work at every stage, from initial creation to storage, verification and account recovery.
The Lasting Lesson
Password cracking has changed enormously since the early days of Unix security research.
The field has moved through dictionary-based auditing, distributed computation, rainbow tables, GPU acceleration and machine-learning techniques.
Yet the underlying principle remains much the same: generate possible passwords, prioritise the most promising candidates and test them efficiently.
Hashcat and John the Ripper demonstrate how effectively this can be done when passwords or their storage methods are weak.
They also help explain why predictable substitutions offer limited protection, why unique salts are important and why deliberately expensive password verification can make a substantial difference.
Future tools will almost certainly become more efficient, and changes in computing hardware will continue to influence the economics of password recovery.
At the same time, authentication technologies such as passkeys are beginning to reduce the need for shared passwords altogether.
Until passwords are no longer necessary, effective protection will depend on several measures working together.
People need unpredictable, unique credentials. Developers need secure storage and verification methods. Organisations need authentication controls that account for both attempted logins and the possibility of data breaches.
A password is only one part of the system protecting an account. Its security depends just as much on how it is generated, stored and verified as on what happens if someone gains access to the information used to check it.
