Hashing a password is only the first step in protecting it. If two users choose the same password, a plain hash produces the same output for both, and attackers can precompute enormous tables of hashes for common passwords and look up stolen values almost instantly. Salting — adding a unique, random value to each password before hashing — breaks those precomputed attacks and forces an attacker to work on every account separately.
This topic builds on what you already know about hash functions and applies it to the practical problem of storing credentials. You will look at how salts are generated with a cryptographically secure random source and stored alongside the hash, how a related secret called a pepper differs from a salt, and how key stretching deliberately makes each hash computation slow. From there the topic moves to the algorithms built for this job: bcrypt, scrypt, and Argon2, each with tunable work factors (and, for scrypt and Argon2, memory cost) that let defenders raise the price of an offline cracking attempt.
While watching, keep three questions in mind. First, which specific attack does each defense stop — rainbow tables, dictionary attacks, or raw brute force? Second, what has to be stored in the database, and what must stay secret? Third, how do you choose parameters: what makes a work factor "high enough" without making legitimate logins unacceptably slow?
This lesson from a foundations-of-cryptography series walks through what happens when a password database is compromised, and introduces salt, pepper, and key stretching as the layered defenses against offline cracking. Expect it to explain why a per-user random salt defeats precomputed hash tables, how a pepper differs from a salt in where it is stored, and why deliberately slow, repeated hashing raises the cost of guessing attacks.
It is the most direct match for the core subtopics here — salting, salt storage, and key stretching — and covers them in one compact, structured lesson from a course-style channel rather than as scattered tips.
This video explains what rainbow tables are and how attackers use them to reverse unsalted password hashes, including the idea of trading storage space for cracking speed through precomputation. It situates rainbow tables within the broader landscape of password attacks and points toward the countermeasures that make them ineffective.
Understanding the attack is what makes the defense make sense, and this video gives the rainbow table concept the dedicated treatment it needs before you can argue convincingly for per-user salts.
A short, focused overview of bcrypt and how it protects stored passwords, likely covering its built-in salting and its adjustable cost factor that slows down hashing on purpose. In a few minutes it gives you the practical picture of why a purpose-built password hashing function is used instead of a fast general-purpose hash.
It grounds the abstract idea of key stretching in a specific, widely deployed algorithm, giving you a concrete reference point for comparing bcrypt with scrypt and Argon2.
Together these videos move from attack to defense to implementation. The rainbow table video supplies the threat model behind MO3, making clear which attack vector salting actually neutralizes, while the salt/pepper/key-stretching lesson supplies the countermeasures themselves — per-user salts, peppers, and iterated hashing — and explains what gets stored where. The bcrypt video supports MO2 by showing why a deliberately slow, salted, work-factor-tunable algorithm beats applying SHA-256 directly to a password, and it gives you a concrete model to extend toward scrypt and Argon2. Taken as a set, they prepare you for MO5: designing a password storage scheme with a modern algorithm, secure salt generation, and sensible work factor tuning.
Note that the videos emphasize bcrypt and classic defenses; you should pair them with the module readings on scrypt's memory-hardness and Argon2's current status as the recommended default.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.