Study Guide
Password Storage: Salting, Stretching and Peppering
How a system can check a password without keeping it: why plain hashes fall to rainbow tables and fast guessing, what a salt, key stretching and a pepper each add, and which purpose-built password-hashing schemes are used today.
Lesson 6.10 Cryptography & PKI
Almost every service stores passwords, and stolen password databases are common. This lesson works out how passwords should be stored so that a stolen database gives an attacker as little as possible, and what storage alone cannot fix.
Stage: Think
Forgot my password
Think it through
A website emails you your old password when you click “forgot password”. What does that tell you about how it stores passwords, and why might that worry you?
- Hint 1: How could it send you something it could not read?
Show what happens
That it can read your password, so it keeps it in plain text or in a reversible form. Anyone who reads its database could read everyone’s passwords too, and people reuse passwords elsewhere.
Think it through
Show the answer
Answer: A. Scramble yours, then compare.
It scrambles what you type in the same way and compares the result with what it stored. It never needs the password itself.
Stage: Explain
The problem: storing passwords
There are three ways a system could keep passwords. Two are wrong.
- In plain text. Anyone who reads the database, an attacker or a curious administrator, has every password immediately. Because people reuse passwords, the damage spreads to their other accounts.
- Encrypted. Better, but encryption is reversible by design. The key has to be somewhere the server can reach, and an attacker who takes the database can often take the key too. Staff with the key can read every password.
- Hashed. The system stores only a hash of each password. To check a sign-in, it hashes what the user typed and compares the result with the stored hash. The password itself is never stored, and a hash cannot be reversed.
Check your understanding
Show the answer
Answer: C. The key can undo it.
Encryption is reversible by design, and the key has to be somewhere the server can reach, so an attacker can often take it too.
Hashing is the right idea. A system built this way cannot tell you your forgotten password, only let you set a new one. A service that can email your old password back to you is not storing it properly.
Stage: Predict
Why a fast hash is not enough
Suppose a service stores each password as a single SHA-256 hash, and its database is stolen. The attacker cannot reverse a hash, but does not need to. The attacker guesses.
Think it through
An attacker steals a database of SHA-256 password hashes. Hashes cannot be reversed. How could the attacker still find passwords?
- Hint 1: Could they hash a guess themselves?
Show what happens
By guessing: hash a likely password, look for that hash in the database, and repeat with the next guess, on their own hardware with nothing to slow them down.
- Take a likely password, such as
Summer2026!. - Hash it.
- Look for that hash in the stolen database. Every account with a matching hash used that password.
- Repeat with the next guess.
This is an offline attack: it runs on the attacker’s own hardware, with no sign-in page to slow it down or lock an account. Two things make it devastating.
- Speed. SHA-256 was designed to be fast, which is what you want when checking a large file. A single modern graphics card can compute billions of SHA-256 hashes every second. Lists of hundreds of millions of real passwords from earlier breaches are freely available, so the common ones fall in seconds.
- Sameness. Identical passwords produce identical hashes. If 4,000 users chose the same password, the attacker cracks all 4,000 accounts with one correct guess, and can even see which passwords are popular before cracking anything.
Check your understanding
Show the answer
Answer: C. One
One: identical passwords produce identical unsalted hashes, so one correct guess opens them all.
Stage: Explain
Rainbow tables and password cracking
Attackers do not have to start from nothing each time.
- A dictionary attack tries a list of likely passwords: real leaked passwords, dictionary words and common variations.
- A brute-force attack tries every possible combination up to some length.
- A precomputed table is the result of doing that hashing work once, in advance, and saving it.
A rainbow table is a precomputed table, built with a clever method that trades computing time for storage space, that lets someone look up the password behind an unsalted hash. Rainbow tables for common hash functions and password lengths have been built and shared, so cracking an unsalted hash of a short password can be a lookup and not a calculation.
The important word is unsalted. Rainbow tables are defeated completely by the next idea.
Stage: Predict
Salting
Think it through
How could you make two users with the same password end up with different stored hashes, without either of them changing their password?
- Hint 1: What could you add that differs for each user?
Show what happens
Add a different random value to each password before hashing, and store that value beside the hash.
A salt is a random value, unique to each password, that is combined with the password before hashing and stored alongside the hash.
When a user sets a password, the system generates a fresh random salt, hashes the password and salt together, and stores both the salt and the result.
What that achieves:
- Identical passwords now have different hashes, because their salts differ. Cracking one account reveals nothing about another.
- Precomputed tables are useless. A rainbow table was built for unsalted hashes. To use one, the attacker would need a separate table for every possible salt, which is not feasible.
- Each account must be attacked separately. One guess can now be tested against only one account at a time.
Worked example: one password, two salts
Two users of a fictional service, Amira and Ben, both choose the password Summer2026!. The service gives each of them a different random salt.
| User | Password chosen | Salt (stored) | Stored hash, first 16 characters |
|---|---|---|---|
| Amira | Summer2026! | 9f2c41d07ab3e6f1 | 5639f5277049bfe8 |
| Ben | Summer2026! | 3be8a0c5d2714f96 | 00ac027b4c25185a |
The hashes were computed with scrypt, one of the schemes in the step on modern password-hashing schemes, and are shortened here. The two passwords are identical, and the two stored values have nothing in common. Someone who steals this table cannot tell that Amira and Ben chose the same password, and each guess must be tested twice: once with Amira’s salt and once with Ben’s.
Without a salt, both rows would hold the same hash, and one correct guess would open both accounts.
A salt does not need to be secret. It is stored in the database next to the hash, and an attacker who steals the database sees it. That is fine: its job is to make each hash unique, not to be a second password. A salt must be unique and random; a username, or one salt shared by every user, does not do the job.
Check your understanding
Show the answer
Answer: A. No, it need not be.
No. It is stored beside the hash; its job is to make each hash unique, not to be secret.
What salting does not do is slow down an attack on a single account. If one person’s password is password1, the attacker reads that person’s salt and guesses it as fast as before.
Stage: Predict
Key stretching
Key stretching makes each hash deliberately slow, or deliberately memory-hungry, to compute.
Think it through
Show the answer
Answer: C. Attackers guess billions.
A genuine user signs in once and does not notice; an attacker needs billions of guesses, and each one now takes just as long.
Instead of hashing once, the scheme repeats the work thousands or millions of times, or requires a large block of memory for every calculation. The amount of work is a setting, often called the cost or work factor.
The reasoning rests on a difference of scale.
- A genuine user signs in once. If checking the password takes a quarter of a second instead of a millionth, nobody notices.
- An attacker needs billions of guesses. Each one now takes a quarter of a second too. An attack that would have taken an hour takes thousands of years.
Because computers get faster every year, the cost is raised over time. Schemes that need a lot of memory go further: they blunt the advantage of graphics cards and custom chips, which have many processing cores and little memory for each.
Stage: Predict
Peppering
Think it through
An attacker steals only the password database, not the server’s other stores. What extra secret could make every guess impossible to test?
- Hint 1: Where else could a secret be kept?
Show what happens
A secret added to every password before hashing and kept somewhere other than the database. Without it, the attacker cannot check a single guess.
A pepper is a secret value added to every password before hashing, and stored somewhere other than the password database.
The pepper is typically held in a hardware security module or a separate configuration store. It is the same for all users.
Its purpose is to cover one specific case: an attacker who steals only the database. Without the pepper, they cannot test a single guess, however fast their hardware is. If the attacker also takes the pepper, the protection falls back to the salt and the stretching, which is why a pepper is an extra layer and never a replacement for them.
Read each row from left to right. The first is inadequate; the second is the modern baseline; the third adds a pepper.
A single fast hash (inadequate)
Identical passwords give identical hashes, and guesses can be tested at enormous speed.
- DataPassword
- OperationHash once with SHA-256Key: none
- DataStored: the hash
Salted and stretched (the baseline)
Every hash is unique, and every guess is slow.
- DataPassword and a unique random salt
- OperationPassword-hashing scheme with a cost settingKey: none: the salt is not a secret
- DataStored: the salt, the cost and the hash
Salted, stretched and peppered
The database alone is not enough to test a guess.
- DataPassword and a unique random salt
- OperationPassword-hashing scheme, then a keyed stepKey: the pepper, held outside the database
- DataStored: the salt, the cost and the result
Check your understanding
Show the answer
Answer: B. The pepper
The pepper: one secret for all passwords, kept apart from the database. The salt is unique and not secret.
Do not confuse: Salt and pepper
- Secret?Salt
- No. Unique to each password. Stored beside the hash. Makes every hash different and defeats precomputed tables.
- Secret?Pepper
- Yes. The same for every password. Stored apart from the database. Makes a stolen database alone insufficient.
Neither one slows a guess down. That is the job of key stretching.
Stage: Predict
Modern password-hashing schemes
Nobody should build these layers by hand. Password-hashing schemes are algorithms designed for the purpose: they generate and include the salt, apply the stretching and produce one string that records the algorithm, the cost, the salt and the hash together.
| Scheme | In brief |
|---|---|
| Argon2id | The recommended variant of Argon2, which won an open competition held to choose a password-hashing scheme. Configurable for time and memory. A common first choice for new systems. |
| scrypt | Memory-hard: needs a large amount of memory for each guess. |
| bcrypt | Long established and widely supported, with an adjustable cost. |
| PBKDF2 | Repeats a keyed hash a set number of times. Not memory-hard, so it needs a very high iteration count; widely available and used where approved algorithms are required. |
Think it through
Show the answer
Answer: A. No, it is too fast.
No. It was built to be fast, which is exactly what helps an attacker guessing offline.
SHA-256, SHA-512 and MD5 are not on this list. They are general-purpose hash functions, built to be fast. Used once, on their own, they are the wrong tool for passwords, however strong they are for integrity checking.
NIST’s digital identity guidelines state the requirement plainly: stored passwords must be salted and hashed with a suitable password-hashing scheme, with a cost as high as practical, and a further keyed step with a secret key stored separately is recommended. That last recommendation is the pepper.
Six steps: three when the password is set and three at every later sign-in. The service is fictional.
Service · when the password is set
Step 1 of 6: Generate a salt
The user chooses a password. The service generates a new random salt for this user alone.
Service · when the password is set
Step 2 of 6: Run the password-hashing scheme
The password and the salt go through a scheme such as Argon2id, at the configured cost. This takes a noticeable fraction of a second, on purpose.
Service · when the password is set
Step 3 of 6: Store the result, not the password
The database stores the scheme, the cost, the salt and the resulting hash. The password itself is discarded.
Service · at sign-in
Step 4 of 6: Look up the user’s salt and cost
The user types a password. The service reads that user’s stored salt and cost from the database.
Service · at sign-in
Step 5 of 6: Hash what was typed, the same way
The typed password and the stored salt go through the same scheme at the same cost.
Service · at sign-in
Step 6 of 6: Compare
If the new hash equals the stored hash, the password was correct. If not, sign-in is refused. At no point was the stored hash turned back into a password.
This is why a salt must be stored: without it, the service could not repeat the calculation.
Go deeper Changing the cost, or the scheme, later
Because each stored value records its own scheme and cost, a service can strengthen its storage gradually. When a user next signs in successfully, the service briefly has the real password and can re-hash it with the new settings. Users who never return keep their older, weaker hashes, which is one reason services ask long-inactive users to reset their passwords.
Stage: Predict
What good storage does not fix
Think it through
Show the answer
Answer: C. No: it is guessed early.
No: it is among the first guesses, so even slow guessing finds it quickly.
Good password storage limits the damage of a stolen database. It does not make a weak password strong.
- A guessable password is still guessable. Stretching makes each guess slow;
Password1is among the first guesses. - Storage is no defence against online attacks, where guesses are typed into the real sign-in page. Rate limiting and account lockout handle those.
- It does not stop a password being given away to a phishing page, or reused on a site that stores it badly.
That is why password storage is one layer among several, alongside multi-factor authentication, checking new passwords against lists of known-breached ones, and supporting password managers.
Stage: Explain
Security+ terminology
The CompTIA Security+ SY0-701 exam objectives list salting and key stretching under objective 1.4. Objective 2.4 lists password attacks, including brute force and spraying.
The objectives do not list peppering, rainbow tables or any named scheme in objective 1.4; they are the standard explanation of what salting and stretching are for.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: B. It can read it.
It can read your password, so it is not hashing passwords properly. Change that password anywhere else you used it.
Apply it
Show the answer
Answer: A. Raise the cost over time.
Raise the cost, re-hashing each password with the stronger setting when its user next signs in successfully.
Apply it
Show the answer
Answer: B. Rate limiting and lockout
Rate limiting and account lockout: password storage is no defence against online guessing.
Stage: Check
Check your understanding
These questions come from the approved revision bank. They were approved under owner-authorised delegated review: the site owner authorised the review and did not read each question individually.
Show answer
Answer: SHA-256 is fast, so an attacker with the hashes can test guesses at great speed
A fast general-purpose hash such as SHA-256 on its own is unsuitable for passwords because an attacker with the stored hashes can test guesses at enormous speed. Speed is the problem, not a benefit. SHA-256 has no practical collisions, and a hash uses no key and cannot be decrypted.
Revision sources: Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: A precomputed table used to reverse unsalted hashes of likely passwords
A rainbow table is a precomputed table for reversing unsalted hashes of likely passwords: the work is done once, in advance, and reused against every stolen database. Random values added before hashing are salts, which are what defeat such tables.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: Identical passwords get different hashes, which defeats precomputed tables
A salt is a unique random value stored with each password’s hash, which makes identical passwords produce different hashes and defeats precomputed tables. Slowing each hash is key stretching, and a secret value kept outside the database is a pepper. A sound scheme does not let anyone read a password back.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: Two different hashes, each stored beside its own salt
A salt is a unique random value stored with each password’s hash, which makes identical passwords produce different hashes. The attacker therefore sees two unrelated hashes and two salts, and cannot tell that the passwords match. Identical or shared hashes would mean no salt was used, and a salt is stored with the hash because verification needs it.
Revision sources: Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: False
False. A salt does not need to be secret. Its job is to make each password’s hash unique, so that a precomputed table is useless and each password must be attacked separately. That works even when the attacker can see the salt, which is why it is stored beside the hash.
Revision sources: Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: To make each guess costly, by making the hash deliberately slow to compute
Key stretching deliberately makes each password hash slow or memory-intensive to compute, so that large-scale guessing becomes expensive. One sign-in is barely affected; billions of guesses are. The aim is cost per guess, not a longer hash, and a password hash is not meant to be reversible.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: A salt is unique per password and stored with the hash; a pepper is a secret stored elsewhere
A salt is unique to each password and stored beside the hash, while a pepper is a secret value added to every password before hashing and stored apart from the password database. Slowing each hash is key stretching, and it is the salt, not the pepper, that differs from one password to the next.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: True
True. A pepper is a secret value stored apart from the password database, for example in a hardware security module. Its value lies in the attacker not having it: if it sat in the same database, whoever stole the hashes would take the pepper as well.
Revision sources: Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: Argon2id
Argon2id, scrypt, bcrypt and PBKDF2 are password-hashing schemes that combine salting and stretching. SHA-512 and MD5 are fast general-purpose hash functions, and a fast hash on its own is unsuitable for storing passwords. AES-256 is encryption, which is reversible, and passwords are not stored as reversibly encrypted values.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Show answer
Answer: A tunable cost that slows each hash; A unique random salt for each password
A salt makes identical passwords produce different hashes, and key stretching uses a tunable cost to make each hash slow so that large-scale guessing becomes expensive. Passwords are not stored as reversibly encrypted values, and a fast general-purpose hash on its own lets an attacker test guesses at enormous speed.
Revision sources: Password Storage: Salting, Stretching and Peppering (Supplementary Study Guide explanation)
Study and revision
Practise through the Cryptography & Data Protection topic. Questions cover why a fast hash is inadequate, rainbow tables, what a salt achieves and why it need not be secret, key stretching, salt against pepper, and choosing a password-hashing scheme; six flashcards recall the main points. Most are learning-only. The questions that have been verified against CompTIA Security+ SY0-701 objective 1.4 are also in the Security+ practice track; that does not mean the lesson covers the whole of an objective, and the lesson does not establish practical experience.
Stage: Consolidate
What to remember
- Store passwords hashed, never in plain text or reversibly encrypted.
- A fast hash lets an offline attacker test billions of guesses; identical passwords give identical hashes.
- A unique salt per password defeats precomputed tables; it need not be secret.
- Key stretching makes each guess slow; a pepper, kept elsewhere, protects against a stolen database alone.
- Use a proper password-hashing scheme; good storage does not make a weak password strong.
Key terms
- Password hashing
Storing the output of a purpose-built scheme, which salts and stretches each password, instead of the password itself.
- Rainbow table
A precomputed table for reversing unsalted hashes of likely passwords.
- Salt
A unique random value combined with each password before hashing and stored beside the hash.
- Key stretching
Deliberately making each password hash slow or memory-intensive to compute, so that large-scale guessing becomes expensive.
- Pepper
A secret value added to every password before hashing and stored apart from the password database.
Common misunderstandings
Encryption is reversible, so whoever gets the key gets every password. Passwords are hashed with a password-hashing scheme, which cannot be reversed.
It is secure as a hash and far too fast for passwords. An attacker can test billions of guesses a second against it.
A salt is stored with the hash and works even when an attacker can read it. The secret value is the pepper.
Salting makes every hash unique and defeats precomputed tables. Slowing each guess is the job of key stretching.
Further reading
- NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management: the section on password verifiers sets out how passwords must be stored.
- OWASP Password Storage Cheat Sheet: practical guidance on choosing and configuring a scheme.
- NCSC: Password administration for system owners: the UK National Cyber Security Centre’s password guidance.
- CompTIA Security+ SY0-701 exam objectives (PDF): objectives 1.4 and 2.4.
Lesson sources and acknowledgements
Sources and scope
- Covered in Session 9 (see the Session 9 Learning Log): rainbow tables and password cracking; and salting, key stretching, peppering and password hashing using modern schemes. The FreeRainbowTables website was among the tutor’s demonstrations; what was shown is not recorded, and that website is not used as a reference here.
- Accuracy qualifications: password storage requires a purpose-built password-hashing scheme, not a single fast hash; a salt differs from a pepper and does not need to be secret; a hash is not encrypted data.
- Independently checked: the storage requirements, including the salt and the separately stored secret key, against NIST SP 800-63B; the named schemes against the OWASP Password Storage Cheat Sheet; and the Security+ wording against the published SY0-701 objectives. These are external references, not course evidence.
- Supplementary explanation: every definition, the three ways of storing passwords, the offline-guessing account, dictionary and brute-force attacks, what a salt does and does not do, the two-salts worked example (its values are recomputed by the site’s checks), the reasoning behind stretching, the role of a pepper, the three-row diagram, the scheme table, the six sign-up and sign-in steps, re-hashing, the limits of good storage and the misunderstandings. These were developed afterwards and are my explanations, not the tutor’s words. The diagrams are original.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the forgotten-password opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. The service and its users in the examples are fictional. The lesson material has an associated lab on hashing and salting; I do not record it as completed, and I have not cracked a password hash or implemented password storage as part of this lesson.
An attack that tries every possible key, or every possible password, until one works.
A secret value that controls what a cipher does. The same algorithm with a different key gives a different result.
Guessing passwords from a list of likely ones, such as leaked passwords, dictionary words and common variations, instead of trying every combination.
Transforming data with a cipher and a key so that it cannot be read without the right key. Decryption reverses it.
Recommended practice that helps people make appropriate decisions where rules do not cover every situation.
A function that turns input of any size into a fixed-length digest. It is one-way and uses no key.
The security objective of keeping information accurate and complete by protecting it from unauthorised or improper modification.
Deliberately making each password hash slow or memory-intensive to compute, so that large-scale guessing becomes expensive.
An older hash function with a 128-bit digest. Collisions for it can be produced in seconds.
Authentication that requires two or more different types of factor, such as something you know and something you have.
Guessing passwords against a stolen copy of the stored hashes, on the attacker’s own hardware, where no sign-in page can slow the guesses or lock an account.
Storing the output of a purpose-built scheme, which salts and stretches each password, instead of the password itself.
A secret value added to every password before hashing and stored apart from the password database.
A precomputed table for reversing unsalted hashes of likely passwords.
Restricting how many requests or connections a source can make in a given time.
A unique random value combined with each password before hashing and stored beside the hash.
A group of hash-function families published by NIST. SHA-256 and SHA-512 belong to the SHA-2 family in current use.
The setting that controls how much time or memory a password-hashing scheme uses for each hash. It is raised as computers get faster.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.