Why Websites Should Never Know Your Password: Hashing, Salting & Peppering | Bits To Billions

How websites store passwords, explained from absolute zero - built from everyday pictures, real breaches, and hashing, salting and peppering demos I ran myself. No security background needed. In December 2009 a company called RockYou lost about 32 million passwords in a single break-in. The passwords were stored in plain text - saved exactly as people typed them - so every one of them spilled at once. That list is still handed around today. The strange part is that a well-built website could have lost the same file and given the attacker almost nothing. This video is the whole idea behind that, from the beginning. A site should be able to check your password without ever actually knowing it. By the end you will be able to explain how: why a hash is a one-way tag, why encryption is the wrong tool, why a plain SHA-256 is guessed billions of times a second, and what a salt, a slow hash and a pepper each add. Every load-bearing number here was run or checked against a primary source first. WHAT YOU'LL LEARN Why storing a password in plain text is the original sin - the RockYou breach, 2009 What a hash really is: a one-way 'blender' that turns any input into a fixed-length tag Hashing vs encryption - and why Adobe encrypting passwords in 2013 was the wrong tool Why a plain fast hash like SHA-256 is guessed billions of times a second on a graphics card Offline attacks: what an attacker does the moment they steal your password table Precomputation and rainbow tables - the 2003 time-memory trade-off that cracks hashes fast Salt: a random value per user that makes every stored hash unique Why a salt kills precomputed tables but does nothing to slow a single guess Slow hashing: the 1979 Unix idea of running the scramble many times on purpose bcrypt and the work factor - dialing the cost up as hardware gets faster Why graphics cards forced a newer idea: memory-hard hashing scrypt and Argon2id - the first choice today, and the settings the standards ask for Work factors: why a login hash should take under a second on your server Pepper: a site-wide secret kept out of the database entirely, so the file alone is useless The full modern recipe: a pepper, a modern hash, a fresh salt, and a real cost The mistakes sites still make - fast hashes, no salt, home-grown schemes, the bcrypt 72-byte trap (Okta, 2024) The biggest fix of all: not keeping a password at all - passkeys and phone sign-in CHAPTERS 00:00 Intro 01:34 Storing the password itself 03:28 A one-way tag 05:52 Scrambling you can undo 08:04 A billion guesses a second 10:39 A random pinch, per password 13:25 A hash you can slow down 15:46 Make each guess need memory 18:10 A secret kept out of the file 20:09 A password stored correctly 22:41 Common mistakes 24:33 Recap SOURCES FTC, United States v. RockYou, complaint and settlement (Mar 2012); Dec 2009 breach, ~32M accounts stored in clear text Imperva, Consumer Password Worst Practices (Jan 2010) - the RockYou password analysis Adobe breach (Oct 2013): passwords encrypted with Triple DES in ECB mode, hints in plain text - Adobe/CSO Online, 4 Nov 2013 LinkedIn (2012): unsalted SHA-1, ~6.5M hashes posted; the 2016 dump reached ~117M accounts - Computerworld, Sophos Morris and Thompson, Password Security: A Case History, CACM 22(11), Nov 1979 - salt and slow DES Oechslin, Making a Faster Cryptanalytic Time-Memory Trade-Off, CRYPTO 2003 - rainbow tables OWASP Password Storage Cheat Sheet (2026): Argon2id m=19 MiB/t=2/p=1 NIST SP 800-63B-4 (2025): salt GTE 32 bits, a keyed hash stored separately, no forced periodic changes, breached-password blocklist RFC 9106 (Argon2, Sep 2021); Provos and Mazieres, A Future-Adaptable Password Scheme, USENIX 1999 (bcrypt) Percival, Stronger Key Derivation via Sequential Memory-Hard Functions, BSDCan 2009 (scrypt) Okta security advisory (1 Nov 2024): bcrypt's 72-byte input limit and a long-username login bypass; pyca/bcrypt 5.0.0 (Sep 2025) now raises on GT 72 bytes Dropbox, How Dropbox securely stores your passwords (Sep 2016) - SHA-512, bcrypt, then a site-wide pepper hashcat benchmark, RTX 4090 (Chick3nman, Oct 2022): SHA2-256 ~21,975 MH/s, bcrypt ~184 kH/s Measured here: SHA-256/MD5 throughput on one core (OpenSSL); bcrypt, PBKDF2, scrypt and Argon2id timings (argon2-cffi, pyca/bcrypt) Every load-bearing number, date and claim here was checked against a primary source before recording. Where sources disagreed, the video says so - and where I got something wrong myself, it says that too. These are standalone explainers - one topic, one video, always from zero. Subscribe and you'll get the next one. #passwordsecurity #hashing #bcrypt #argon2 #websecurity #cybersecurity