Passwords, Hashes, and Salt

When a website checks a password, a secure design should not need to store the original password as readable text.

Instead, systems commonly store a hash of the password.

A cryptographic hash function takes input and produces a fixed-length output. If the input changes, the output changes.

For this course, the important idea is not the mathematics inside the hash function. It is the defensive design pattern:

password → hash function → stored hash

When the user signs in later, the system hashes the password they entered and compares the result with the stored value.

Hashing is not encryption

Encryption is designed to be reversible with the correct key.

Hashing is designed as a one-way transformation.

That means a password database should not need to "decrypt" the password during login.

This distinction matters because students often use the words encode, encrypt, and hash as though they mean the same thing.

They do not.

• Encoding changes representation so data can be stored or transmitted in another form.
• Encryption protects data using a key and is intended to be reversible by an authorized party.
• Hashing creates a one-way digest used for comparison and integrity-related purposes.

You will revisit those distinctions later in the cryptography unit.

Why plain hashes are not enough

Suppose two users choose the same weak password:

robotnix123

If the system hashes both passwords the same way with no additional input, both stored values will match.

That leaks information. An attacker who obtains the hash database can see that the two users probably share the same password, even without knowing what the password is yet.

A salt helps address this problem.

A salt is a unique random value added to the password before hashing.

Conceptually:

password + unique salt → hash function → stored hash

Two users with the same password should now produce different stored hashes because their salts are different.

Salt is not a secret password

A salt does not have to be hidden in the same way a password does.

Its job is to make large-scale precomputed guessing less efficient and prevent identical passwords from automatically producing identical stored values.

It does not make a weak password magically strong.

If a password is short and predictable, an attacker can still attempt guesses. Good password storage and good password choices solve different parts of the problem.

Classroom CyberChef lab

Use only teacher-provided or invented sample strings. Never paste a real password into CyberChef or any classroom demonstration tool.

Use a sample such as:

robotnix-lab-2026

Part 1: hash the sample

Using the teacher-approved CyberChef activity, produce a hash for the sample string.

Record:

• the exact fictional input
• the hash operation used
• the resulting output

Part 2: change one character

Change the sample to:

robotnix-lab-2027

Hash it again.

Compare the outputs.

The purpose is to observe that a small change in input produces a very different digest.

Part 3: add two different salts

Use two fictional salts, for example:

• A7f!2q
• M4x#91

Combine each salt with the same fictional password and hash the results.

Record what changed and why.

Do not treat this exercise as a recipe for building a production password system. Real password storage uses dedicated password-hashing approaches and implementation details that are beyond this introductory lab. The goal here is to understand why stored passwords should not be plain text and why unique salts matter.

Breach reasoning

Consider a fictional breach report:

A service reports that an authentication database was exposed. The company says passwords were not stored in plain text. Each password was stored as a salted hash.

What can you conclude?

You can conclude that plain-text password storage was not the stated design.

You cannot conclude that every password is safe.

Why?

• users may have chosen weak passwords
• passwords may have been reused on other services
• the hashing method may be poorly configured
• attackers may attempt guesses offline
• exposed account information can still create phishing risk

A stronger storage design reduces risk. It does not erase the incident.

Password reuse and credential exposure

The Garden State Cyber curriculum also asks you to think about known credential exposure.

A public breach-notification service can help a person discover whether an email address appeared in a known breach, but there is an important classroom rule:

Do not enter real student passwords into any breach-checking service.

If the class demonstrates breach awareness, use teacher-approved sample identities or discuss the concept without exposing personal credentials.

The defensive lesson is this:

If one service is breached and the same password is reused elsewhere, the damage can spread beyond the original service.

That is why password uniqueness matters even when a service stores passwords correctly.

Analyze three storage designs

Design A

The database stores usernames and readable passwords.

Design B

The database stores a hash of each password, but identical passwords produce identical stored values.

Design C

The database stores a unique salt and a derived password hash for each user.

For each design, answer:

1. What information would an attacker receive if the database were exposed?
2. What weakness is visible in the design?
3. Does the design protect against password reuse on another service?
4. What can the organization do after the breach?
5. What should the user do?

Build a password-defense diagram

Create a diagram with these stages:

user creates password → system derives stored value → attacker obtains database copy → attacker attempts guesses → user and organization respond

At each stage, add one defense.

Possible categories include:

• long unique passphrases
• MFA
• safe password storage
• login monitoring
• rate limiting on online attempts
• credential reset after exposure

Then mark which defenses belong to the user, the service, or both.

Evidence for Lesson 2

Submit:

• your CyberChef observation table using only fictional sample strings
• your comparison of the three storage designs
• your password-defense diagram

Finish with two sentences:

A salted hash helps because...

A salted hash does not solve...

The second sentence matters. Security controls are strongest when you understand their limits instead of treating them like magic.