YanoSec
Progress0 of 152 lessons complete

Course / 07 Security / Lesson 05 of 08

Passwords, hashes, and dumps

Estimated time: 14 min reading · 10 min activity

A service needs to check a submitted password without keeping a readable copy. It stores a salt and a password-hash result. At sign-in, it applies the same password-hashing method and settings to the submitted candidate with that salt, then compares the new result with the stored result.

A salt is a value chosen separately for each stored password record; it is normally public and stored with the result. It prevents the same password from having one reusable result across accounts. Password-hashing methods such as Argon2id are deliberately costly to evaluate so copied records are harder to guess against. A salt alone does not make an easily guessed password strong.

Before you begin

Estimated time
14 min reading, 10 min activity. Setup and optional practice may take longer.
Where you work
Read the fictional cards in any current desktop or mobile browser. No installation, account, password tool, directory deployment or network request is required. Use only the evidence supplied on this page.
Without a lab
The page prints the evidence needed for the activity. Write your classifications and reasons in notes, then compare them with the activity rubric. This practices reasoning; it does not reproduce a live incident or tool operation. Reading works without JavaScript. Answer checking requires JavaScript and a secure browser context; saving progress also requires usable browser storage.

After this lesson you can:

  • Point to the salt label and the stored result in a fictional password record.
  • Say whether a matching check requires the candidate to be stored.
  • State one thing a salt changes and one thing it does not change.

01Example

Follow the fictional comparison for Mina. The assigned labels let you reason about a match without running a password function. Use only these synthetic candidates.

Account: mina
Candidate offered: lamp-42
Salt label: salt-mina
Stored result label: verifier-mina
Assigned combination label: verifier-mina
The labels match, so the card accepts the candidate.
Stored columns: salt-mina and verifier-mina. lamp-42 is not stored.
lamp-7 with the same salt is assigned verifier-other and does not match.

02What is stored

The candidate is the password offered for checking. The stored record in this model contains a salt label and a result label, rather than the candidate. Real records also need the algorithm and its cost settings. The labels below illustrate equality only; they are not genuine digests and must not be used as passwords.

Copied password-hash records remain sensitive because someone can test guesses away from the sign-in service. This is offline guessing, which bypasses that service's request limits. Slow password hashing makes guesses more expensive; it does not prevent all guessing. A fast general hash such as SHA-256 alone is unsuitable for this storage job. In NIST terminology, verifier usually means the checking service; the card's verifier-mina label means its stored result.

Follow a salted password check and see that the stored label is not the candidate.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

lamp-42lamp-7
Assigned combination

Candidate offered: lamp-42 Salt label: salt-mina Assigned combination label: verifier-mina

met · lamp-42 with salt-mina is assigned verifier-mina.
Fixed stored fields

Stored columns: salt-mina and verifier-mina. lamp-42 is not stored.

met · Stored verifier-mina equals the assigned label.
Apply the stated rule
Card accepts

The assigned labels match. No hash is calculated and the candidate is not a stored column.

This is assigned-label equality, not real hashing; the offered candidate is not a stored column.

The assigned labels match. No hash is calculated and the candidate is not a stored column.

Follow the explanation

  1. The assigned labels match. No hash is calculated and the candidate is not a stored column.
  2. Only the candidate label changes; salt-mina and verifier-mina remain the stored fields.
Read every state and value

1. The assigned labels match. No hash is calculated and the candidate is not a stored column.

Case
match
Conditions inspected
Assigned combination · Fixed stored fields
Decision shown
Yes

2. Only the candidate label changes; salt-mina and verifier-mina remain the stored fields.

Case
miss
Conditions inspected
Assigned combination · Fixed stored fields
Decision shown
Yes
This is assigned-label equality, not real hashing; the offered candidate is not a stored column.

03Read noor's record

The activity uses cedar-9 and a result label that does not match. The drawing repeats the worked comparison. The text card is the required description.

Original fictional labels. Not a person's password and not a computed digest. No password-hashing function was run. Do not reuse the candidate labels.

Words on this card
Password: the candidate that is offered.
Salt: a unique label stored beside the result. Here it is a name, not a generated random value.
Password-hashing method: a deliberately costly operation applied to the candidate and salt. Argon2id is one suitable method when configured appropriately. The password hash is its stored result. Fast SHA-256 alone is unsuitable for password storage.
Stored verifier: the label this card keeps for the result. NIST uses verifier for the service that checks a sign-in. That is a different use of the word.
Dump: a copy of stored salts and results. This card is not a copy of real values.
Guessing: trying candidates away from the sign-in page. This lesson does not practice it.

Worked comparison
Account: mina
Candidate offered: lamp-42
Salt label: salt-mina
Stored result label: verifier-mina
Label assigned to the combination of lamp-42 and salt-mina: verifier-mina
The labels match, so this card accepts the candidate.
Stored columns: salt-mina and verifier-mina. lamp-42 is not a stored column.

Other candidate: lamp-7 with salt-mina
Label assigned to that combination: verifier-other
The labels do not match, so this card rejects lamp-7.

Activity comparison
Account: noor
Candidate offered: cedar-9
Salt label: salt-noor
Stored result label: verifier-noor
Label assigned to cedar-9 and salt-noor: verifier-other
The labels do not match.
Check: the stored column remains verifier-noor. cedar-9 is not stored.

Same candidate, different salt
If account ada also offered lamp-42, and ada's salt label was salt-ada, the assigned result label would differ from verifier-mina.
The salt does not make lamp-42 hard to guess. It stops one result label from standing for every account that offered the same candidate.

Download the password-role card

Compare a derived result with the stored result
Compare a derived result with the stored resultModel. A teaching model drawn by hand. It shows the idea, not real tool output.A candidate password and a salt label enter a password-hash function. Its derived result is compared with the stored result. In this modeled storage design, the database retains the salt and derived result instead of the candidate password. The candidate still has to be handled during checking. The labels represent digests; no digest values were computed for the diagram.

Download the comparison drawing. The text card is the description.

  1. List the offered candidate, the salt label, and the stored result label for noor.
  2. Compare the assigned combination label with the stored result label.
  3. Check: the stored column remains verifier-noor. cedar-9 is not stored. The labels do not match.
  4. Stop. Do not run a password-hash function and do not look for a real password list.

04Optional challenge

Allow about ten minutes. Give two accounts the same synthetic candidate but different salts. Explain why their stored results should differ, then explain why someone with a copied record can still test a guess against that one salt. No calculation is required.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Password case A: synthetic record labelsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Account: Uma.
Declared method: suitably configured Argon2id.
Stored columns: salt-uma and stored-uma.
Offered candidate: river-6.
Assigned result for river-6 with salt-uma: result-other.
These are invented labels, not computed password-hash values or real credentials. Candidate text is not a stored column.

Password case B: separate synthetic comparisonOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Account Val stores salt-val and stored-val.
Candidate moss-8 with salt-val is assigned stored-val.
The same candidate moss-8 with a different salt-wen is assigned different-wen.
Different salts change derived result labels; they do not make an easy candidate difficult to guess.

06Explain your prediction

Optional written self-check: List candidate, method, salt, derived result and stored result separately. Describe a comparison without calling it decryption or claiming a synthetic label represents a computed or recovered real password.

07Common mistakes

If you stored cedar-9 in the record, you kept the candidate. The card's stored columns are the salt label and the result label.

If you treated SHA-256 as the password-hash function, you chose the fast hash OWASP rejects for this job.

If you treated the salt as a second secret that makes guessing useless, you gave the salt the job of password strength.

References

  • OWASP Password Storage Cheat Sheet

    Introduction, hashing versus encryption, and salting. No plain text. Use a slow password hash such as Argon2id, scrypt, bcrypt, or PBKDF2. A unique salt stops a precomputed table from matching every record and stops identical passwords from sharing a result. SHA-256 is named as too fast for password storage. Minimum settings were not copied into an exercise.

  • NIST SP 800-63B-4: Strength of passwords

    Offline attacks follow a database copy of hashed passwords. Central verifiers store salted, iteratively hashed verification secrets. In that publication, verifier means the checking service. This lesson's card uses verifier for the stored label and says so.

  • OWASP Authentication Cheat Sheet

    The password-storage pointer. It sends storage details to the password-storage sheet.