Welcome back to Cybersecurity from Zero to Hero, the series where I learn security from scratch and write it down while the confusion is still fresh. In post three we separated authentication from authorization. Today we go inside the most common authentication factor on earth: the password, and the strange one way math that protects it.
Here is the question that unlocked this whole topic for me. When you click Forgot Password, why does every decent site send you a reset link instead of just telling you your password? The answer is not policy. The answer is that a well built site literally does not know your password. And that is exactly how it should be.
🥣 Hashing: the one way blender
When you create an account, a good site never stores the password you typed. Instead it runs the password through a hash function and stores only the result.
A hash function is like a blender. Drop in an apple and you get a very specific smoothie. Drop in the same apple tomorrow and you get the same smoothie. But no power on earth un-blends the smoothie back into the apple. That is the whole trick: same input always gives the same output, and the process only runs one direction.
So the login flow works like this. You type your password. The site blends it. It compares your fresh smoothie to the smoothie it stored on day one. Match means you knew the password. The site verified your password without ever storing it.
Now the Forgot Password mystery solves itself. The site cannot email you your password because all it has is the smoothie. The only honest option is a reset link that lets you make a new one.
💻 What I actually did: hashing my first strings in Python
This is the first hands on in the series that uses code, and it needs nothing but Python's standard library. Fifteen lines, no installs:
`python
import hashlib
def hash_it(text):
return hashlib.sha256(text.encode()).hexdigest()
print(hash_it("hello"))
print(hash_it("hello"))
print(hash_it("Hello"))`
Three things jumped out the moment I ran it.
Same input, same output. The first two lines print identical hashes. Deterministic, as promised.
Tiny change, chaos. Capitalizing one letter produced a hash with no resemblance to the first. This is called the avalanche effect, and it is why hashes make great tamper detectors. It is the same property we used in post one when we verified a download with a checksum. Different purpose, same math.
Any size in, same size out. I hashed a single letter and then a whole paragraph. Both came out as 64 hex characters. A hash is a fingerprint, not a container.
If you followed my Python series, this is where the two tracks officially shake hands. If not, you can still run those five lines in any online Python playground and see it yourself.
🔓 So how do passwords get cracked at all?
If hashing cannot be reversed, why do we keep hearing about cracked password databases? Because attackers do not reverse the blender. They run the blender forward, billions of times.
Take every common password, hash each one, and compare the results against the stolen database. Whenever a hash matches, you have found someone's password. Precomputed versions of this are called rainbow tables, and against common passwords they work depressingly well.
This is exactly why two defenses exist:
Salting. The site adds a random string to your password before hashing, and stores the salt alongside the hash. Now two users with the same password get different hashes, and precomputed tables become useless. Every guess has to be recomputed per user.
Slow hashing. SHA 256 is designed to be fast, which is great for checksums and terrible for passwords, because fast for you is fast for attackers. Password storage uses deliberately slow functions like bcrypt or argon2 that turn billions of guesses per second into thousands. My demo above uses SHA 256 because it ships with Python and shows the concepts perfectly, but hear this clearly: real systems must never store passwords with plain SHA 256.
And the math behind length beats everything. Each extra character multiplies the guessing work. This is why every serious guide says the same boring thing: long unique passwords in a password manager beat clever short ones every time. In post two my worst risk score was password reuse. This post is the reason it scored so high: one cracked database anywhere unlocks every account where I reused that password.
🤔 What confused me today
If hashes are one way, how does my password manager show me my passwords? Because a password manager does not hash, it encrypts. Encryption is a two way door that opens with a key, in this case my master password. Hashing is for verifying, encryption is for retrieving. Two different tools that beginner me had filed in the same drawer.
What are collisions? In theory two different inputs could produce the same hash, since infinite inputs map to fixed size outputs. For SHA-256, nobody has ever found one, and the numbers involved are absurd. Older functions like MD5 have real, demonstrated collisions, which is why you still see MD5 in tutorials but never in serious modern systems.
⏭️ Next in this series
Post 5 covers multi-factor authentication, including what actually happens inside that six-digit code app and why the codes keep working with your phone in airplane mode. The hands on part sets one up and proves that offline trick. Follow the series so you do not miss it.
Top comments (1)
This is a useful framing because the user-facing symptom is simple: a good system cannot tell you the password back. I would add one more operational point: password reset flows deserve the same care as storage. A strong hash does not help much if the recovery path becomes the softer identity check.