How Logins Work: Hashing and Salting Passwords

Unit IV opens with that line from Chapter 10 because it sets the direction for the whole unit: a strong password matters, but so does everything that happens to it after you create it. Over seven lessons you will follow a password from the moment a website stores it, through the ways criminals steal it, to the tools that protect you today: password managers, multi-factor authentication and passkeys. We begin behind the scenes, on the website's side of the login box.

What you'll be able to do

Explain how a service should store your password and why a stolen password file still endangers weak or reused passwords.

• Describe in plain terms what a service checks when you press "Sign in".
• Explain what hashing and salting do for you, and what they cannot do.
• Decide which of your own habits still matter even when a site stores passwords properly.

How a login check works

Dr. Al-Doori opens Chapter 9 with a story more than two thousand years old: guards at a river crossing told friend from enemy by how travellers pronounced a single word. The principle has not changed. A password is a shared secret. You know it, and the service needs some way to check it.

The simplest way to check would be for the service to keep a list of every username and password and compare what you type against that list. That is exactly the danger. A file of passwords on a server is one of the most valuable things an attacker can steal, because a single break-in could expose every account at once. So well-run services never keep your actual password. They keep something derived from it.

Hashing: a one-way fingerprint

A hash function is a piece of mathematics that turns any input (a word, a sentence, a whole file) into a scrambled value of fixed length, called a hash. Three properties matter to you:

• Same input, same output. Type the same password again and you get the same hash, so the service can compare hashes instead of passwords.
• A tiny change gives a completely different output. Change one character and the new hash looks unrelated to the old one. Because every hash has the same length, it also reveals nothing about how long your password is.
• One-way. There is no practical way to run the mathematics backwards from the hash to the password.

So when you sign in, the service hashes what you typed and compares the result with the hash it saved when you created the account. If they match, you are in. The service never needs to keep the password itself.

The book explains "one-way" with an analogy from arithmetic: multiplying two prime numbers is quick, but working out which two primes produced a large number is slow. That is a helpful picture of maths that is easy forwards and hard backwards. Keep in mind that it is an analogy: password hash functions are not actually built on prime numbers.

Why hashing alone is not enough

Here is the catch. Attackers who steal a file of hashes cannot reverse them, but they do not need to. They can guess and compare: take a likely password, hash it, and check whether the result appears in the stolen file. This is called offline guessing, because it happens on the attacker's own computers, where the website's limits on login attempts never see it. OWASP, a widely used source of security guidance for software developers, notes that this kind of cracking is cheap with modern graphics processors and cloud computing, especially when a fast hash is used or salt is missing.

Two weaknesses make plain hashing risky:

1. Identical passwords give identical hashes. If thousands of users chose the same common password, they all share one hash, and cracking it once reveals all of them.
2. Lists can be prepared in advance. Attackers can hash millions of common passwords ahead of time and simply look up the stolen hashes. Large precomputed lookup lists of this kind are called rainbow tables.

Two defences fix most of this:

• Salt. A salt is a random value, different for every account, that is mixed into the password before hashing. Now two people with the same password get different hashes, and prepared lookup lists become useless. The attacker has to start from scratch for every single account.
• Deliberately slow hashing. Ordinary hash functions are designed to be fast. For passwords, speed helps the attacker. Password-hashing schemes such as Argon2id or bcrypt are built to be slow and costly on purpose: barely noticeable for one login, but a heavy burden for anyone trying billions of guesses.

The current US standard for digital identity, NIST SP 800-63B-4 (final version, July 2025), requires services to salt passwords and to store them using a suitable password-hashing scheme of this kind.

What this means for you

You cannot see how any website stores your password, and even excellent storage only slows attackers down. Salting and slow hashing buy time; they do not protect a password that sits near the top of every guessing list. A short or common password can still be found quickly, and once found, it works on every other site where you used it.

That leaves you with habits that matter whatever the site does:

• Make passwords hard to guess: long and random (Lesson 4.3), or generated for you by a password manager (Lesson 4.4).
• Never reuse a password, so one breach cannot open your other accounts (Lesson 4.2).
• Add a second step or use a passkey on important accounts (Lessons 4.5 and 4.6), so that a cracked password is not enough on its own.

Real-World Example

Imagine two websites are breached on the same day, and both lose their password files.

Site A stored fast, unsalted hashes. The attacker looks up the stolen hashes in a prepared list, and within a short time every account with a common password is exposed. Because identical passwords share one hash, cracking one popular password reveals everyone who chose it.

Site B stored salted hashes made with a deliberately slow scheme. No prepared list helps; the attacker must guess account by account, and every guess is expensive. Accounts protected by long, random passwords are, in practice, out of reach. But a user who picked a very common password is still found, simply because that password is among the first guesses tried.

Now imagine a user called Sam had the same short password on both sites and on his email. Site B did its job well, yet Sam's email is at risk because of Site A. Storage quality is the website's job. Password quality and uniqueness are yours.

From the Book to 2026

What the book teaches. Chapter 9 explains that a reputable company stores a one-way hash rather than the password itself, that hashes have a fixed length and change completely with the smallest change of input, and that a stolen password file therefore does not automatically hand attackers your password. Chapter 10 adds that criminals hash lists of common passwords and look for matches in stolen files.

Why it made sense. These are the core ideas of password storage, and they remain true. Understanding them is the foundation for everything else in this unit.

What has changed. Security guidance has evolved since the original text. Attackers now have cheap access to huge computing power and to billions of real passwords from past breaches, so offline guessing against fast, unsalted hashes is cheap. Current guidance now recommends, and NIST SP 800-63B-4 requires, that services add a unique salt to every password and use a deliberately slow password-hashing scheme. OWASP lists Argon2id as its preferred option and advises against fast general-purpose hashes for passwords.

What to do now. Assume that any site might one day lose its password file. Protect yourself with long, unique passwords (most easily through a password manager), and add multi-factor authentication or passkeys to your important accounts.

Watch: How NOT to Store Passwords! (Computerphile)

This short talk walks through the mistakes services make when storing passwords, one approach at a time, which makes the case for salting easy to see. It was recorded some years ago, and the presenter himself says advice changes and urges developers to look for current guidance, which is why this lesson adds the point about deliberately slow hashing.

As you watch, notice:

• The giveaway he describes for a site that stores plain-text passwords: it can email your actual password back to you when you ask for a reminder.
• Why he rejects encryption for this job: it is two-way, so anyone who obtains the key can read every password, and identical passwords still look identical (made worse in his example, where password hints were stored alongside them).
• How a random salt for each user makes the same password produce different stored values, and his closing reminder that even then a password like 123456 is found almost at once.

The video reinforces what you just read — the lesson is complete without it.

What Would You Do?

You click "Forgot password" on a small online shop, and a few minutes later an email arrives showing your actual password in plain text. You used that same password on one other site.

Decide what you would do, then compare your reasoning with the note after the Knowledge Check.

Knowledge Check

Key Takeaways

• Well-run services store a salted, deliberately slow hash of your password, never the password itself.
• Hashing is one-way, but attackers can guess and compare offline, so weak and common passwords still fall.
• A site that can show you your own password is not storing it safely.
• You cannot see how a site stores passwords, so use long, unique passwords everywhere.
• Multi-factor authentication or a passkey means a cracked password is not enough on its own.

Further Study

Optional and external; not needed to complete the lesson.

• Tom Scott — YouTube Doesn't Know Your Password

Sources

• NIST — SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management
• NIST CSRC — SP 800-63B-4 publication record (final, July 2025)
• NIST CSRC — Glossary: hash function
• OWASP — Password Storage Cheat Sheet
• Dr. Tahseen Al-Doori — Cyber Security Essentials, Chapters 9 and 10