Storing passwords sounds simple until you consider what happens when a database is stolen. If passwords sit in plain text, a single breach hands an attacker every account immediately — and because people reuse passwords, the damage spreads to other services. The natural fix, running each password through a cryptographic hash like MD5 or SHA-256, is better but still weak: those functions are designed to be fast, which is exactly what an attacker guessing billions of candidates per second wants. Precomputed rainbow tables make matters worse, since identical passwords produce identical digests.
This topic walks through the fixes that modern systems actually use. A unique, randomly generated salt per user makes precomputation useless and ensures two users with the same password get different stored values. Dedicated password hashing algorithms — bcrypt, scrypt, and Argon2 — add a deliberately tunable work factor (and in scrypt's and Argon2's case, memory cost) so that each guess is expensive for the attacker while still fast enough for a legitimate login. You will also see the login verification flow: the system retrieves the stored salt and parameters, recomputes the hash from the submitted password, and compares the results.
As you watch, keep a few questions in mind. What exactly gets stored in the users table, and why does the salt not need to be secret? Where does a pepper differ from a salt? How would you choose a work factor, and what should happen to it as hardware gets faster? Finally, notice how the attack methods described in the third video map back to the specific defenses introduced in the first two.
A short, system-design-oriented walkthrough of how passwords should be kept in a database. Based on its title and channel, it is likely to contrast plain-text and naive hash storage with a salted, dedicated password-hashing approach, and to show the registration and login verification flow including what columns a users table actually holds.
ByteByteGo is known for tight, well-diagrammed system design explanations, and at under four minutes it gives a compact overview that frames the whole topic — storage format, salting, and login-time verification — before you dive into details.
This video focuses on what an attacker can do with a leaked password database and how salting, peppering, and hashing change that calculus. Expect coverage of why fast general-purpose hashes are a poor fit for passwords, how a per-user salt defeats precomputed tables, and how a secret pepper stored outside the database adds a further layer.
It is the clearest match for the salting subtopic and is the only one of the three that explicitly addresses peppering, giving you the vocabulary distinction between salt and pepper that the module expects you to use precisely.
An IBM Technology explainer covering five common methods attackers use to obtain passwords. Based on the title and description, it is likely to walk through techniques such as brute-force and dictionary guessing, credential theft and reuse, and social-engineering approaches like phishing, along with practical countermeasures.
Understanding the attacker's toolkit is what justifies work factors and salting in the first place; IBM Technology is a reputable producer, and this video supplies the threat-model context that makes the defensive design choices in the other two videos meaningful.
Together these videos target the password-specific portion of the module. The ByteByteGo and mCoding videos directly support MO2 and MO5 by showing why general-purpose hashes are insufficient, how salts (and peppers) are generated and stored, and how a dedicated algorithm with a tunable work factor underpins a sound storage-and-verification design. The mCoding video also reinforces MO1 by highlighting the speed property of cryptographic hashes that makes them unsuitable here. The IBM Technology video supports MO3 by surveying real attack vectors and their countermeasures, giving you the threat model you will need when evaluating brute-force, dictionary, and rainbow-table risks. MO4's integrity applications are addressed elsewhere in the module; use these videos to build the credential-storage foundation.
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.