Attacking Password Hashes: The Principles — Ethical Hacking: Penetration Testing Methodology

Passwords are rarely stored as plain text; they are transformed first. Understanding how, and what that transformation does and does not protect against, is essential both to test systems responsibly and to defend them properly. This lesson explains hashing and salting in principle, preparing the ground for the attack techniques in the next lesson.

Why passwords are hashed, not stored directly

If a system stored your exact password in its database, anyone who could read that database (an attacker, a careless employee, a backup left unprotected) would immediately have every user's real password. To avoid this, well-designed systems store a hash of the password instead: the output of a one-way mathematical function applied to the password.

A good hash function has a key property: it is easy to compute in one direction (password to hash) but computationally very hard to reverse (hash back to password). When you log in, the system hashes the password you just typed and compares the result to the stored hash; it never needs to know or store your actual password at all.

Why "one-way" does not mean "unbreakable"

If reversing a hash directly is practically impossible, how can hashes ever be attacked? The answer is that attackers do not reverse the function; they guess a candidate password, hash it the same way, and check whether the result matches the stored hash. This distinction matters enormously: the security of a hashed password depends heavily on how easy it is to guess, not only on the mathematical strength of the hash function itself.

This is why a short, common password remains weak even when correctly hashed with a strong algorithm: guessing "password123" and hashing it takes almost no effort, and the comparison will succeed instantly if that was indeed the real password.

The role of salting

A salt is random data added to a password before hashing, unique to each user, and stored alongside the hash (it does not need to be secret). Salting exists to defeat a specific and once very effective attack: a precomputed table of common passwords and their hashes, built once and reused instantly against any system (sometimes called a "rainbow table"). With salting, the same password produces a different hash for every user, because each user's salt is different, which makes precomputed tables useless, since an attacker would need a separate table for every possible salt value, which is impractical.

Modern, well-designed systems also use hash functions specifically designed for password storage, which are deliberately slow and resource-intensive to compute, unlike hash functions designed for speed (used, for example, to verify that a downloaded file was not corrupted). This deliberate slowness directly raises the cost of guessing many candidates quickly, which is the whole point from a defensive perspective.

What a tester actually examines

During an authorised engagement, a tester who obtains access to a system's password hashes (for example, through the kind of access described in chapter 4) looks at several things, mostly to assess and report risk rather than to perform a full, exhaustive cracking campaign on every account:

Which hashing approach is used, as far as can be determined, and whether it is a modern, purpose-built password hashing method or an outdated, fast, general-purpose one, which is a meaningful finding on its own, independent of any individual password's strength.
Whether salting is present, since its absence is itself a significant, reportable weakness.
A representative, limited sample of password strength, for example attempting a small number of very common passwords against a handful of accounts (with explicit client agreement on exactly this kind of test, as covered in the next lesson) to illustrate the real-world risk, rather than attempting to recover every single user's password, which is rarely the actual goal of a professional report.

A principle, not a step-by-step attack

This lesson deliberately stops at principles. The next lesson covers dictionary and brute-force techniques for actually attempting to guess passwords from hashes, and it repeats the legal and ethical boundaries around this kind of testing in more detail, since guessing attempts, even conceptually simple ones, are exactly the kind of activity this course's brief insists must only ever be practised in your own lab, with explicit scope and client agreement in any real engagement.

Legal reminder

Even obtaining a system's password hashes requires that the access leading to them was itself authorised, and further use of those hashes for guessing attempts needs to be explicitly covered by the agreed scope and techniques, exactly as discussed for exploitation in the previous chapter. Hashes obtained during a real engagement are sensitive data and must be protected and deleted according to the data-handling rules from chapter 1.

Your fil rouge: assessing Lighthouse Labs' approach

Write a short fictional paragraph for your Project Lighthouse notes, as if you had reviewed how Lighthouse Labs stores its user passwords (invented for the purpose of this exercise, since there is no real system to inspect): state whether your fictional scenario uses a modern, purpose-built password hashing method with salting, or an outdated, fast, unsalted approach, and write one sentence explaining the real-world risk difference between the two, as you would in a report.

Your turn: explain the risk difference

Two companies store user passwords differently. Company A uses a modern, purpose-built password hashing method with per-user salts. Company B uses a fast, general-purpose hash function with no salt at all. Both suffer a database breach exposing their password hashes. Explain, in your own words, why the practical risk to users differs between the two companies, even though in both cases "only hashes", not plain passwords, were exposed.

See a solution

For Company B, the lack of salting means precomputed tables of common password hashes can be checked near-instantly against the stolen data, and the fast hash function makes guessing large numbers of additional candidate passwords cheap and quick, so a meaningful fraction of weak and even moderately strong passwords are likely to be recovered quickly. For Company A, the per-user salts make precomputed tables useless, and the deliberately slow, purpose-built hashing method makes guessing many candidates far more costly in time and computing resources, so recovering passwords, especially stronger ones, takes dramatically longer and may be impractical at scale. In both cases, weak, very common passwords remain at risk eventually, but the practical, immediate danger to most users is far higher for Company B.

Tip

When you read "we only store hashed passwords" in a company's security statement, remember it is a good start, but the real question is which hashing method and whether salting is used. A finding worth a line in any report.

Key takeaways

Hashing transforms a password into a one-way value, so systems never need to store the password itself.
Attacks against hashes work by guessing candidates and comparing results, not by reversing the hash function.
Salting defeats precomputed-table attacks by making each user's hash unique even for identical passwords.
Purpose-built, deliberately slow password hashing methods raise the cost of guessing attacks significantly.
A professional tester assesses the hashing method and salting as findings in their own right, not just individual password strength.

With the principles in place, the next lesson looks at how dictionary and brute-force techniques actually attempt to guess passwords, and how to do so responsibly in your own lab.